EDITS.WS

Author: Nathan Wrigley

  • #75 – Mark Westguard on Launching a Plugin Into an Already Competitive Market

    Transcript

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case launching a plugin into an already competitive market.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the podcast, I’m very keen to hear from you, and hopefully you get you or your idea featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox and use the form there.

    So on the podcast today we have Mark Westguard. Mark is an agency owner and developer behind the WS Form plugin. And he’s on the podcast to chart his journey in the WordPress space, and the different ways he’s explored to grow the reach of the plugin.

    First up, we talk about why mark started to use WordPress. As you’ll hear he already had a successful agency, but he could see that the path to profitability was becoming harder each year. WordPress plugins offered the chance of recurring revenue, which was appealing.

    Users of WordPress will know that there are many form solutions. Both free and paid plugins are available, and can handle almost any scenario you might imagine.

    We get into what made Mark pick this as an area to invest in. Surely it would have been easier to work on something brand new? Mark does not think so. He could see gaps in the market and built his solution to cater to those. This involved plenty of market research and analysis of where to put his development efforts.

    We then move onto the subject of turning a well-developed plugin into a viable business. It’s one thing to build a product, but if you’re going to make it commercial, much of the work will revolve around ensuring that the world knows about it. Marketing is a relentless enterprise, and one that you should not ignore or underestimate.

    This might mean getting yourself out into the community to meet with other WordPressers, appearing on podcasts, or sponsoring WordPress events. There’s no perfect answer. Just run with what works and try out new things all the time.

    After that comes support. Mark’s pretty clear your product will succeed or fail based on how you handle support requests. He thinks that the development of a plugin inevitably leads to support tickets, and this needs to be factored in right from the start.

    We also get into the subject of pricing, and what Mark feels was the right price to pitch his plugin. Is the WordPress ecosystem guilty of expecting a lot from plugins at prices which are realistic? How much of the functionality, if any, should be given away in a free version? And how did he decide which features to charge for?

    Towards the end of the podcast we stray into the plugins use of AI, and how Mark was an early mover in this area. What can be done with forms and AI, and does he see AI as a technology which is going to grow in the future?

    If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

    And so without further delay, I bring you Mark Westguard.

    I am joined on the podcast today by Mark Westguard. Hello, Mark.

    [00:04:34] Mark Westguard: Hey Nathan, how are you?

    [00:04:35] Nathan Wrigley: Very good, thank you. Mark is joining us today. We’re going to have a chat all about, well, I guess building plugins in what is a competitive marketplace. Marketing, launching, creating, having an idea for what plugin you’re going to decide to create. But before we do that Mark, I wonder if you wouldn’t mind spending just a few minutes, give us a potted history of yourself. Who you are. How come you’ve ended up developing on top of WordPress. All of that good stuff.

    [00:05:04] Mark Westguard: Yeah. About 26, 27 years ago out of university, I decided I was going to start a web agency. Back when we had to teach companies what the web was. Nowadays everybody knows what the internet is. Back then, we were trying to convince companies that they needed a website. And started an agency. We were quite successful. We were the UK’s second fastest growing web agency at the time. And went through the whole dot com boom and bust, and have been in the web industry ever since.

    And about, I want to say about 14 years ago, I actually got into the licensing game. I was marrying my wife and, I’m not a US citizen, my wife is. So we had a bit of an international wedding and we needed to RSVP guests from both countries. So I built an RSVP system, and I thought, oh, other people may want to use this. And I actually licensed it and ended up licensing that to a company called Condé Nast, which people may be familiar with.

    They produced Vanity Fair Magazine and also Brides Magazine. I White labeled it to them. And that was kind of my entry into the licensing world. And that company went on for about six, seven years. I had that company for about six, seven years. And then I got back into the web agency game again, and that’s when I started using WordPress.

    So that was around about, I want to say, probably about 10 years ago now. We were back in the agency game, building websites and sat down one day with my wife and I said, look, I’m building all these wonderful things for people, great websites, but also software development and apps and things like that. And decided I want to get back into the licensing game and building a plugin seemed to be a good way of doing that.

    And sat down with my team at the time and said, look, what do you not like about WordPress? What is, you know, a challenge for you when we’re building websites. And forms came up, and we thought, okay, let’s try and tackle the form problem. And that’s basically what started WS Form, and where I am now.

    So really it came from a lot of experience in the web industry, just trying to tackle an issue that we come across personally as a company and wanted to improve on. And that’s where WS Form was born.

    [00:07:15] Nathan Wrigley: Do you have a relationship with WordPress going back years and years? Or in your case, did you pick WordPress because you knew you wanted to create some sort of solution that you could sell into the market, and WordPress at the time was the dominant force, so that’s where you ended up? Or have you been building websites with it for many, many years?

    [00:07:34] Mark Westguard: We had been building websites with it, yeah, for quite a long time. I was not the one that introduced my company to it. It was actually one of my employees who went to a WordCamp. Really liked the WordPress product, was very keen about it. It took me, I’ll be honest, it took me a while to warm up to it because we were originally building websites from scratch. Literally from scratch, and building the admin things for them.

    So the idea of having a pre-built content management system was quite new to me at the time. So, it’s something that we’ve been using for at least 10 years. We’re not by any means like some other companies that have been there for the full 20 years. But yeah, 10 years of building websites, and then more recently getting very much more involved in the community and building plugins.

    [00:08:17] Nathan Wrigley: So the desire was to build a plugin, to sell something into the marketplace, give away a free version as well. And you’re casting around and you’re thinking, okay, what thing could we build?

    [00:08:29] Mark Westguard: Right.

    [00:08:29] Nathan Wrigley: Why forms? Of all the things it feels that in the last 10 years even, or more, there have been some incumbent players. I mean, some players have come, some players have gone. But there’s been some solid competition, some rivals in that space. What on earth were you thinking there? Launching into a marketplace which you could have already described as possibly saturated.

    [00:08:54] Mark Westguard: Partially madness I think. I think that we saw a genuine gap in the market there. There were some frustrations that we had and that other people had as well. You’re right, it was a very saturated area. It’s a very well established part of WordPress.

    Every website needs a form. We don’t particularly like building them. Without a form, you’re not going to get any feedback from your customers or from potential customers or whoever’s using your website. We saw that there were better ways that we could do certain things that were lacking in some of these form plugins.

    For example, mobile responsiveness, actually being able to build a fully responsive form with break points. We weren’t very happy with the number of plugins you had to add to get a form plugin to do what we wanted it to do. There were performance issues. There were styling issues. So all these things were things that we could improve upon. And so we embarked on that journey.

    We thought it was going to take, five, six months and four years later we’re still here building more and more for it. So it’s certainly been a big challenge. So basically we just saw a genuine need there and thought we’d go ahead and tackle it.

    [00:10:03] Nathan Wrigley: I wonder if you’d, if you had done any market research in the WordPress space, aside from forms? You know, whether you’d thought about building, oh, I don’t know, a page builder or a caching plugin. You know, all these other things where there’s lots of scope, there’s a lot of ways to differentiate yourself and so on.

    So the question really is, what kind of market research did you do inside the WordPress space, if any, to figure actually forms is it? You mentioned that you found a need and you described all of the different things that you felt were lacking. I wondered if you’d ruled out other types of plugins?

    [00:10:36] Mark Westguard: We did, we looked at other plugins in the space that we were using as well. I think the thing that attracted me to it personally is probably my programming background and my desire to integrate one thing with the other. Which has been a big part of WS Form. Before I had my agency, I was working for a company called Sequin, who are now owned by IBM and I worked in their communications team, and I worked on networking.

    So we would integrate one machine with another. The challenge of making that integration process easy with WS Form was something that attracted me as well. One very simple example, a lot of form plugins you have to go off, get an API key or set an app up. It was a very long process just to get your website connected to a third party platform. And I saw that a lot of these platforms we’re now using OAuth, which is a very simple way for users to be able to connect their platform well from one platform to another.

    And so I wanted to incorporate that into WS Form, which is one of the things that we’ve done. I think it was looking around at where we saw that there was a gap in the market. Granted, a small gap in the market because it was a saturated area. But also just a desire to build something that would interest me as well.

    [00:11:46] Nathan Wrigley: I’m wondering if there were people listening to this podcast who have a desire to get into WordPress plugin development. Let’s stick with plugins, particularly. I know there’s a whole range of different marketplaces, themes and so on. But if we just stick with plugins, I wonder what your opinion is of the marketplace. Whether or not the growth of WordPress, which inexorably seems to go up.

    It’s the low forties at the moment. I don’t know where it’ll be the next time we hear that figure. But it does seem to just sort of keep edging up. So the audience is growing, but equally the number of players getting in, developing plugins, it feels like there’s not just a plugin for that, but there’s often multiple plugins for that.

    And so speaking to people who are considering this as a career, do you have any pearls of wisdom? Any advice for people in that space? Is WordPress still a land of bounty, or is it more, as you might imagine everywhere else, a story of hard work, trial and error, occasional failure and so on?

    [00:12:55] Mark Westguard: I think that there are two distinct types of developers in the WordPress space. You’ve got people that just genuinely just want to build a bit of software that’s open source, and want to support the community that way. And they’re not necessarily interested in monetizing it. Those that do want to monetize it, you’ve really got to run that business like any other bricks and mortar business. Don’t think that you can just write a plugin, put it in the repo, and suddenly start making huge amounts of money from it, because it just doesn’t work that way.

    You’ve really got to market it properly. You’ve got to be, in my opinion, if you want to be successful in the WordPress space, you’ve got to be part of the community. And that means giving back. If you want to be successful, but also respected in the industry, you’ve got to give back in the community and be part of it.

    In terms of other advice I would give would be, and we can talk about this later, but marketing. And different things that I’ve tried with marketing that have worked and haven’t worked. It’s very easy to pump a lot of money into marketing and get nowhere with it.

    I’ve found that the whole WordPress ecosystem is a very different way of marketing. There’s a lot of established brands there. Be it people like yourself, Nathan, with podcasts. Or people in the hosting industry that they’ve got a big customer base there and you need to be in with those people.

    But you know, you don’t just approach them and say, hey, here’s my product. You’ve got to build genuine relationships with people. The WordPress community is just a wonderful group of people that all want to help each other and all want to respect each other. And you’ve got to be part of that. You’ve got to be respectful and you’ve got to be friendly and get on with these people and build genuine friendships and relationships with them in order to grow.

    [00:14:33] Nathan Wrigley: Let me just rewind a little bit, but I will come back to marketing that we’ve just mentioned, but you mentioned the community and how you thought being involved in the community was a good way to figure out the path that you want to take, but also to get some, I’ll use the word credibility in the WordPress space.

    What do you mean? What things have you done in the community which you feel have either given back, so that’s in one direction, but also have benefited you, so that’s other direction. What things have you undertaken? What events have you been to? Things have you sponsored, whatever it may be.

    [00:15:08] Mark Westguard: Yeah, I think in terms of relationships with people, that can certainly help you get exposure of a product. So maybe contributing to a podcast or something. It’s only small amounts The thing that I’ve found is there’s no single channel in the WordPress space where you can say, hey, here’s my product, and expect thousands of people to learn about it.

    It’s a very distributed community of lots of small channels. And you need to be involved with all those different channels to get a bigger voice. So, yeah, contributing to say podcasts. Just getting people using the product that enjoy using the product and those people can become almost brand advocates naturally because they like using the product.

    I mean, obviously you’ve got to have a good product in the first place. And that’s someone we can talk about. What product do you decide that you want to build in the first place? I think that, going back and then I’ll come back to your point, is there’s a lot of plugins out there that can be done better. There’s plenty of scope out there for improvement. You don’t have to become the next big thing that no one’s thought about. So I think that’s an important thing to consider.

    So, WordPress has like five for the future, for example. And I know that’s not very well defined at the moment. They’re still trying to work out other ways to say, hey, you know, you’ve done that. We’d like to recognize that as part of that five for the future. But doing WordCamps is one of the biggest things I spend money on.

    Primarily it’s to meet new customers. Demo the product. But it’s also building genuine relationships at these events, which has been really great for me. So, meeting people in all walks of life form hosting companies to other plugin companies. I’ve met people at other plugin companies at WordPress events, like WordCamp, and we’ve built an integration between us and then you’ve got co-marketing going on there.

    So anywhere where you can identify a business that has an existing customer base that you could potentially plug into by developing something that will genuinely help those customers is a good way of increasing your of sphere of influence.

    And it’s also just doing things like giving back to things like Big Orange Heart, for example. And we’re also doing something right now with GiveWP where they’re going to be giving away three websites to three nonprofits. And we try to donate licenses wherever we can to help out with that. That in turn, WS Form will appear on something, and it may only be seen by a handful of people, but the more and more you do of that, the more brand awareness you get.

    And I’m about doing that type of community work rather than trying to pump money into Google AdWords or a Facebook ad or you know, an Instagram ad or whatever it may be. Really you are pushing your product in people’s faces. I find that if people are recommending your product, you’ve got a much higher conversion rate, and really word of mouth business is the best business you can get.

    [00:18:04] Nathan Wrigley: You mentioned that you’ve been in different lines of work in the past, and I don’t know if in those lines of work you were customer facing. In other words, if you were selling directly into that market. So you may able to answer this question. But, in the round, broadly speaking, how easy or difficult has it been, in your estimation, to get a product to the point where it’s self sustaining. It justifies itself.

    It’s no longer a pet project. Something you do at the weekends and in the evenings. It’s now your actual core business. I wonder how easy that’s been or if it’s been surprisingly difficult. If there’s any challenges come your way and you’ve thrown your arms in the air and said, oh, wish I’d never got into this in the first place.

    [00:18:45] Mark Westguard: Yeah, it’s been a big challenge. And it’s been very different from a business model that I’ve been used to. I used to be a web development agency where I would get in the car, go to a meeting, meet a company and sell a website to them. Or I would join an RFP process, you know, and pitch myself against two or three other companies and hopefully win the business.

    With this, it’s been very, very difficult. I’m sure there are some plugins out there that come out that people have jumped on and have been very successful. But building a sustainable subscription-based business is a challenge. We are selling high volume, low price products. Our base price is $59, which doesn’t go a long way to pay the bills. So you need a lot of those in order to start building a sustainable business.

    The nice thing about it is when you get to the point where you’ve got that critical mass and you’ve got enough people renewing their licenses, and fortunately we have a very good license renewal rate, it starts to become a sustainable business and it starts to, in effect, snowball.

    But it’s taken us a good, I’d say three, four years to get to where I’d say that we’re in the clear, we’re profitable, we’re doing great. I actually went to a Post Status event, in Oklahoma a few years ago, and I met some other plugin developers there. It’s actually one of the first times I’d sat down and had the chance to have a beer with somebody about their WordPress business.

    And it was really interesting sitting and talking to them. And gauging from them where they are in their business. They were saying after year two, three, if you’re starting to make good profit then, then you’re on the right path. So it certainly wasn’t an overnight success, and I wasn’t expecting that. I expected this to be a much more long slog to get to where we are.

    And really, I guess it depends on your business model. There are other people in the industry, you know, take for example Newsletter Glue, a newsletter plugin for WordPress. They changed their business model from lots of small customers to much bigger customers and less of them. Which I think is really interesting and quite brave of them to do.

    But that seems to be working well for them. I guess it just depends on what plugin you’re developing and what your price point is and as to how long it’s going to take. But it’s certainly taken a lot longer than I expected it to.

    [00:20:57] Nathan Wrigley: But I guess you, having had those chats in the past, you were prepared for that. Let’s say two year slog. Where it wasn’t necessarily going to be a case of, okay, I’ll just toss this into the marketplace and by this time next year it’ll all be ticking over. There was hard work. Support to be done. We’ll get to that, but all of these things, continual development and so on.

    A takeaway from that would be, yeah, don’t expect riches quickly. Address the problem of the next couple of years, and I guess in your case, you had other work, other lines of work which you could rely on and develop this at the same time?

    [00:21:34] Mark Westguard: Yeah. This was very much a career change for me because I was in the agency space building websites. Which I love doing, but the web development space has changed significantly in the past five, six years. And that’s something I recognized early on. Another reason I wanted to get back into licensing.

    We had the likes of Wix. We had the likes of Squarespace, and to an extent now even WordPress making websites so easy to build. I mean, I’ve actually built a website for a friend yesterday. I used Kadence and I had something whipped up in an hour. 10 years ago that would’ve taken us three weeks and a team of five people to do it.

    So, my industry was dwindling in terms of the revenue that I could create from it, and that’s why I, you know, I moved to this space. But I think, going back to your point, there’s a lot of hurdles with building a plugin. You’ve got to find the good plugin that you want to build. You’ve got a development period to actually build that product, which can be a considerable investment.

    Then you’ve got a period of time where you’ve got to build that customer base up. Where you’ve not got the income coming in. So for me, I was looking at three, four years before I was breaking even. And I was very fortunate that I had my agency to fall back on. So I was running those in parallel. For some people that may be a need to get some investment. A loan or whatever to get through that period, and actually build the product.

    [00:22:53] Nathan Wrigley: Let’s get to the pricing piece before we return to the marketing, because I always think this is a curious conversation. On the one hand, you’ve got a really interesting crowd of people in the free open source software space. A large amount of things which are literally free as in beer. You don’t pay anything. You can use it how you like.

    And, then you’ve got obviously people like yourself who are developers and need secure an income and so, there’s this tension, this conflict between price high to ensure that you can survive and you don’t need to go through thousands of users in a year. You can do it with a modest amount of sales.

    And then there’s this constant pressure to drive down prices and make licensing as cheap as possible. A, because everybody likes things that are as cheap as possible, but also you’re in competition with other people and that slightly skewed marketplace, which free open source software, like WordPress, has. There’s definitely a little bit of tension in pricing created there.

    How did you decide on the pricing? You know, did you have that pang of, okay, I’ve got to go in low because that’s what the market can take. I’ve got price against what all of these other plugins are doing. I’m curious about how you make those decisions.

    [00:24:11] Mark Westguard: Looking at competitors in the space was a big part of that. Looking at what they were pricing themselves at. Because at the end of the day, somebody looking for a form plugin is maybe going to shop around at the, maybe the top four or five that they find online, right? And if my price was way over the others, they would’ve just chosen one of the other companies.

    Back then, it was harder for me to differentiate myself against those other plugin companies. That’s changed over time. I’ve really found a niche more in the kind of enterprise, developer level, form development. That price sensitivity, I saw it in Facebook groups, in even tweets and things like that. People saying, well, this is, you know, even $10 more than the other customer.

    So it’s a very price sensitive area, in all of the plugins that are out there. You’ll find that they’re very, they all have very similar prices. I am told constantly that I am too cheap, and that I should put my prices up. But I feel like I found a sweet spot and I’m happy with it right now. So I don’t really want to rock that boat and change things.

    The other thing to consider is what is your pricing model? There’s a lot of talk around lifetime deals and annual subscriptions, and I have stuck adamantly with annual subscriptions because I wanted to build a sustainable business. And I’ve seen far too many plugins, some of them fail, because of offering lifetime deals.

    They’ve got a critical mass of lifetime deal customers, and then there’s no additional income coming in. They’ve got to constantly find new customers to stay alive. Whereas having the annual subscription, that enables me to reinvest that money in the business. Enables me to continue providing good support to those customers on an ongoing basis. And it builds a firmer business. You’ve got that annual recurring payments coming in, which helps keep the business afloat.

    So, yeah, it was a combination of getting the pricing right, and also getting the actual business model correct. And also the products that you offer. So we have three different versions. We have a personal, which is $59, all the way up to an agency, which gives you everything for 249 currently. And getting those prices right across those different product levels was important too. But I think we’ve got a pretty good sweet spot now, and I’ve got no plans to rock the boat.

    [00:26:25] Nathan Wrigley: But it was a journey. You’ve arrived at this model over time.

    [00:26:30] Mark Westguard: Yeah, even the naming of the product types was a challenge as well. You know, what do we called it? And we decided with agency in the end, that seemed to fit quite nicely with the customers that we were working with.

    [00:26:42] Nathan Wrigley: Given the market that you’re selling into, and we talked about it just moments ago in terms of the pricing and, I don’t really know how to describe this, but the community that gathers around open source software, I think there is a slight difference to that community. And obviously WordPress is just dominated by that flavour

    Coming from commercial, enterprise clients, that kind of thing. I’m just wondering if your marketing had to shift. If there’s any sort of subtle difference or advice that you would give to anybody? Do you go in for the hard sell? Do you go big on Black Friday? Do you modify your language in a certain way that seems to be appealing to the WordPress community? It’s hard to encapsulate what that question means, but I hope you’re getting a flavour of what I’m trying to say.

    [00:27:24] Mark Westguard: It was interesting when we did our first WordCamp that in order to be at WordCamp, we weren’t allowed to say that we were the best form plugin out there, or that we were the ultimate form plugin out there. There’s always a tendency with businesses to say that isn’t there? To say, yeah, we’re the best.

    And I usually, if I ever see that, I’m like, okay, well then you’re not the best. But, that was interesting to me. We actually changed our slogan to just say, build better forms, rather than the best form plugin out there. That started me on a journey with WordPress in terms of being very careful about what we said as a product.

    And it also started me on the journey, obviously with WordCamps, about being very respectful of the WordPress industry. Being very respectful of the WordPress community, and finding out very soon on that they don’t like being told that you are the best product. They want to hear that from respected names in the industry.

    They want to hear that from other users that are in the community, or people that they work with. So I found that the best way for us to grow was genuinely to do two things. Build a good product, that worked well and did better than other products. And secondly, offering exceptional support. And that’s something that we’ve really, really focused on.

    So, support for us is our number one focus. And good support results in good word of mouth about your product. It results in good reviews. And it results in people wanting to talk about your product, and spreading the word about the product in the WordPress community.

    That in itself has made the process of getting the name of WS Form out there, a much longer process. But I feel that at the end of it, we’ve got a stronger brand name out there and we’ve got a stronger product.

    [00:29:14] Nathan Wrigley: You mentioned there good support, and obviously if I’m a purchaser of a plugin, nobody thinks that’s a bad idea. So on my side, customer, good support, great. On your side, supplier, good support, well, presumably that is a lot of hard work. It would be interesting to explore that message for people who may be wanting to launch a plugin.

    Is support a question of, you know, occasionally logging into your email and dispatching a few emails once or twice a week. Or is it more than that? I’m guessing that support is essentially, well, I’m going to make up a figure. Half time might be spent on it?

    [00:29:52] Mark Westguard: If you are building any type of plugin, any kind of significant plugin in WordPress. Know that in about two, three years, you’re going to be running a support business. That’s a very big primary function of what you’re doing. So I think you’re right. We’re probably about half the time developing the product, and probably half of the resources goes towards supporting the product.

    If you are not providing good support, I personally believe we provide exceptional support. We bend over backwards for customers to really try and help them out. We very much steer our products based upon the support that we’ve received from people and feedback that we get from customers. It’s a critical part of the business and, yes, ongoing development is a very important part of that.

    Every time you develop something else for your product, it’s something else you’ve got to support. So you’re constantly improving the product and causing more support for yourself.

    I think it’s important as a plugin developer to ensure that you provide as much front end content as possible to cut down those support requests, and make it easier for the customer to find what they want. So, for example, we have an extensive knowledge base. We also analyze what people type in when they’re making a support request to us, and we will fire back suggested articles back to them, to help them get to the information they want without having to raise a support ticket and wait for us to reply.

    So yeah, support is a critical part of the business, and will be a large part of what you do if you are in a similar space to what we are.

    [00:31:21] Nathan Wrigley: I suppose in a sense, if you are running a subscription business, an annual subscription business, where you are hoping that people when the renewal for the license comes up, you’re hoping that they happily walk through that process and, sign up for another year. So the support in a sense is about just maintaining that, isn’t it?

    If you secure the initial sale and then the support is lousy. You really are not giving yourself a fighting chance on next year’s set of scheduled payments.

    [00:31:51] Mark Westguard: Yeah. I always remember when I was at university and I did a year out in industry, and they had something written on the wall, and it’s always stuck with me. And it just said, easy to do business with, was one of their terms that they’d like to use with their staff.

    And that stuck with me. And I think if you are easy to do business with, which means providing good support, providing a good product. These people will renew, and they will continue to use you. I can say hand on heart, when we lose a customer, it is usually because, maybe an agency is no longer working with a customer anymore. Or they’ve had a website redesign or something like that.

    We don’t have people saying, don’t like the product, don’t like your support. And that is testament to the hard work that we’ve put in to building the product. And, you know, having the passion to provide that good customer service. So I think yeah, you know, in answer to your point, having that good customer service will absolutely bring people back, and keep them using your product.

    [00:32:44] Nathan Wrigley: Developing the plugin itself, that’s on your schedule, isn’t it? You can decide, right, I’m going to allocate this amount of time. But the support stuff, that just comes in when it comes in. You’ve got no control over that. I am genuinely curious what that does to your work-life balance.

    Now, I don’t know if you’ve got a support team, or if you handle all of that yourself. But how that is for you. Because it sounds like a large part of this podcast is really trying to speak to people who may be wanting to go into this, and this seems like a good rabbit hole to go down. It sounds like that’s a big burden, right? And you’ve got to be available during holiday time, weekends, all sorts.

    [00:33:21] Mark Westguard: Yeah, I think my personality doesn’t help either. If I see a support ticket, I want to help that person as quickly as I can. It’s weird, some days you can maybe get two support tickets. Other days there could be a huge flurry of 20, 30 tickets. There’s no average that happens every day.

    And when you get that big flurry, I like to clear our support queue every day. And that can sometimes mean late nights to get that. And being a small business, that’s what you do. You’ll have those late nights of helping people out with stuff, particularly if something maybe is a bug in the software that you really want to get fixed and make sure that that doesn’t affect anybody else.

    So, yeah, some days can be quiet. It’s funny because I have a lot of European customers. By the time I wake up in the US I can usually gauge how busy the day’s going to be, based upon the number of support tickets that I’ve got. But fortunately the vast majority of the tickets that we get are, how do I do this? And I can point them in the direction of a knowledge base article that we have. So those are easy to fix.

    If I find that we are getting one or two of the same question, I will write a knowledge base article and refer them to that, in the hope that that will then cut down that particular question in the future as well.

    So, support and building knowledge bases or help documentation is a massive undertaking. It’s taken a lot of time to get all that content put together and built. And that’s another thing that plugin developers should certainly take into account is, as well as building your product you’ve got to document it.

    Even on the small plugin, you know, some of these. WS Forms are huge plugin. It is tens of thousands of lines of code. There are much simpler plugins out there. But even though smaller plugins need maybe a good page documentation to make sure people understand how to use it.

    [00:35:05] Nathan Wrigley: You have got a lite version in the WordPress repository. So just to be clear, for anybody who’s listening to this podcast. There’s a paid version. You can go to Mark’s website, we’ll link in the show notes, but you can also go and download a free version. I’m always curious as to how you make the decision of what to, well, I’m going to say strip out. Maybe that’s completely the wrong way around.

    Maybe it’s more, okay, this is what we’re going to build for the repository and then we’ll add on other things. But forgive my language there. How do you come to decide that, okay, this is free. This is not free. What is the process that’s going on there? Because obviously you want to, in some way entice people. But you don’t want to make free version utterly useless otherwise, well, nobody’s ever going to dream of heading in the pro direction.

    [00:35:56] Mark Westguard: Yeah, and some plugin developers do make their plugins almost useless, so that you have to pay for the pro edition. We actually wanted to provide a lite edition that was fully usable. So for example, there are some plugins out there that won’t actually store the submissions so that you can view them in the WordPress admin.

    And I thought, well, that’s a bit mean. It’s a form plugin. You need to be able to see your submissions and have them as a backup in the database. So we gave a little bit back. We gave back a little bit more than maybe some of the other form plugins do, really to contribute again to the community. To enable people to use the product for free.

    And you can build a perfectly usable contact us form, or inquiry form, using our lite edition. And then it was really more of the technical, more advanced features, that we cut out. So things like conditional logic, e-commerce. Some of the field types that were a little bit more advanced, like Google address and things like that.

    Obviously we want people to upgrade to the pro edition because that’s how we pay the bills. But we wanted the lite edition to be usable and useful to a lot of people that just want to use a free product. So, you know, that’s another contribution that we give back. We don’t throw up huge admin notices that say, hey, upgrade.

    We’ve got very, very subtle things in the product that encourage people to upgrade. So we’ve tried not to be, you know, there’s a lot of plugins out there, a little bit over the top on the notifications on the admin panel. So we’ve tried to cut that down and be a bit more reasonable. We hope that people enjoy using the lite edition for that reason.

    [00:37:27] Nathan Wrigley: Although this isn’t directly related to the plugin necessarily. AI at the minute is all the hotness. And I did notice that you had taken the time to build an integration with OpenAI for your form plugin. And I’m curious, what was the thinking there? Because when I approach a form, I’m always thinking, okay, there’s blank fields. I just them out and click return, and obviously wait for a response to come back and so on. What thing does OpenAI or AI in general bring to a form?

    [00:37:59] Mark Westguard: Two things for us. So, first of all, from a purely commercial side of it, we like to integrate in with new systems because it opens up a new audience for us. And also OpenAI had a lot of marketing going on in the industry. People were very interested in it. I was as well, I was curious about it.

    I researched OpenAI and I found out that they have a moderation endpoint in their API, which means I can send it some content and it will tell me whether or not that content has bad language in it or bad words, or is it violent content or whatever. And I thought, hey, wouldn’t that be great for WordPress spam protection?

    So I looked into it more and I was able to integrate in that moderation piece, so that when a form is submitted, it analyzes what the person’s typed in. If there’s anything to do with violence or whatever in there, it will then reject that form submission. Then I looked at the other endpoints such as the image generator. So people may be familiar with that, with DALL-E. Where you can type in, you know, make a boat floating on the moon, or whatever crazy thing you want to create an image about.

    And I was able to pull that into a file upload field, and I thought, well, that’ll be great for creating an avatar for a new user or an image for a blog. So that got incorporated. And then I thought, well look, all these other endpoints that OpenAI offer or actually have a use case, on a form. So we use the, what they call a completion, which is where you type in a question and it will then give you a response.

    That has actually been very useful for our customers that have a supporting environment. You can actually tell OpenAI what your business is, where your support page is, et cetera, and it will actually respond almost as if they’re an employee of the company. And we’ve had some people using that application. So, after researching it, found it had quite a lot of application in the form industry.

    So that’s why we had the OpenAI integration. And we’ve just launched it with GPT-4. Which at the time is the latest model that they’ve released. So, it’s actually been a very popular feature. And that add-on incidentally is free of charge whilst OpenAI is still effectively in beta. We’ve got that add-on free of charge.

    [00:40:12] Nathan Wrigley: Yeah, it’s really curious. I’m fascinated by the whole AI debate. This is not necessarily related to the whole AI debate, but ever since the web came around, essentially we’ve been presenting pictures and words to people, and the only way to really respond to that is through some kind of form interface. That’s what you’ve got.

    But a few years ago, along come these devices which sit in the home, which you can talk to. And I just wondered what, it’s a really bizarre question. A bit of a random question. I wondered what your thoughts are about that kind of technology. Getting into the whole, speaking to the internet instead of filling out forms and, perhaps even putting on goggles and all of that kind of stuff. Whether or not you feel that this is something that you need to be mindful of. Do you have any sense that the world is moving more towards voice?

    I feel that, certainly from my perspective, I found that to be an interesting technology for a period of time, and now the interest in that has completely waned and those voice devices in my home really only get used for starting and stopping songs, that kind of thing.

    [00:41:19] Mark Westguard: It’s funny isn’t it? Because computers, as we know it, have been around for, what, 50, 60 years now. A keyboard and a computer. And I’ve still got a keyboard in front of me. I still like typing on a keyboard. I don’t like talking to computers.

    My children are very different. They like talking to computers. I think it’s a generation thing to a certain degree. To your point about keeping up with this technology. That’s very much another reason why we had the OpenAI add-on. I wanted to be familiar with that technology. It is changing the way that we are doing things. People are writing code with it now.

    They’re generating images with it. Like it or hate it, it’s changing the way that we’re doing things. It’s being incorporated into products. We are actually working on another AI integration into WS Form, which would almost enable you to develop a form based upon what you type in.

    They have a code model for OpenAI, and we’ve been able to take a prompt and actually build a form from what you’ve typed in. So you can say, build me a form for a doctor’s office for booking an appointment, and it will build a form for you. So something that we’ve got to be on top of and we’ve got to adapt and work around it and take advantage of it.

    [00:42:39] Nathan Wrigley: That’s so fascinating because in a way it doesn’t in any way cut out the need for a form solution. It merely creates that templating system. So I know that your form solution, for example, when you create a form, you’ve got loads of different templates for different scenarios, and you can click on a button and so that job’s done.

    In this case, you would be able to fill that out by just writing in plain text. So, I would like a form with three fields. It’s for my kid’s birthday party. And it’s highly unlikely that you’ll have got a template for whatever scenario I can contrive. But this potentially purports to do that and create a custom form based upon what you tell it. That’s fascinating.

    [00:43:19] Mark Westguard: At least a foundation for that. And then on the other side of it, the OpenAI add-on that we have can turn your form into an interactive component where they get an immediate response. And that’s done through prompt engineering with OpenAI. So prompt engineering is where behind the scenes you are giving OpenAI a little bit more context about the question, and then incorporating the question from the user into that particular prompt that you’re sending to them.

    And that kind of comes back to that customer support aspect I was talking about earlier on. So I can configure it, and if they ask a question, it can be asked as if it’s your company. So just for an a very quick example, you could say, hey, I am hosting company X, and then the customer may ask, please tell me what your hosting packages are.

    OpenAI will then use its knowledge of your business to respond to that and give you a list of the packages they have, directly in that form. Rather than them having to submit the form and wait for a response from a human. It can be used very much to compliment existing forms that you’ve got on your website, to make them more user friendly, and to give customers a quicker response. And if we didn’t have that OpenAI component, we would not be on that bandwagon. So I’m glad that we have that.

    [00:44:34] Nathan Wrigley: So it’s almost like a chatbot creation. Whereas at the moment chatbots are very much the realms of SaaS, you are saying that some of this technology can be pulled in. So obviously there is a SaaS side if you like, and it’s OpenAI. But you can bind that to a form and the form can then become much more interactive than it currently could ever be.

    [00:44:55] Mark Westguard: Correct. Yeah. It’s funny because people have said to us, can we use your form for a chat interface? This opens that up. This enables it to be a chat. Granted it’s an AI response, but tuned properly it can be very effective. It’s quite scary what you can get back from it.

    [00:45:12] Nathan Wrigley: The future is either bright or scary, depending on which side of the fence you sit there. Mark, we’ve probably used up the time that we’ve got available, so just before we pass it over to the audience. I’d like you to, to tell us where you can be found. That could be a social media platform or your website address. Whatever you like. Just tell us where we can find you.

    [00:45:32] Mark Westguard: Yeah, so the main website is wsform.com. You can find me on Twitter. I am at Westguard, that’s w e s t g u a r d. And for WS Form, it is w s _ f o r m.

    [00:45:46] Nathan Wrigley: Somebody had WS Form. Did they?

    [00:45:48] Mark Westguard: They did and they’ve done nothing with it.

    [00:45:51] Nathan Wrigley: Well, Mark an absolute pleasure chatting to you. Thanks for talking to us about your plugin development journey, and growing your business, and forms in general. I really appreciate it.

    [00:46:00] Mark Westguard: Yeah. Well, thank you for having me on the show. I appreciate it.

    On the podcast today we have Mark Westguard.

    Mark is an agency owner and the developer behind the WS Form plugin, and he’s on the podcast to chart his journey in the WordPress space and the different ways he’s explored to grow the reach of the plugin.

    First up, we talk about why Mark started to use WordPress. As you’ll hear, he already had a successful agency, but he could see that the path to profitability was becoming harder each year. WordPress plugins offered the chance of recurring revenue, which was appealing.

    Users of WordPress will know that there are many form solutions. Both free and paid plugins are available and can handle almost any scenario you might imagine. We get into what made Mark pick this as an area to invest in. Surely it would have been easier to work on something brand new? Mark does not think so. He could see gaps in the market, and built his solution to cater to those. This involved plenty of market research and analysis of where to put his development efforts.

    We then move onto the subject of turning a well-developed plugin into a viable business. It’s one thing to build a product, but if you’re going to make it commercial, much of the work will revolve around ensuring that the world knows about it. Marketing is a relentless enterprise and one that you should not ignore or underestimate. This might mean getting yourself out into the community to meet with other WordPressers, appearing on podcasts, or sponsoring WordPress events. There’s no perfect answer. Just run with what works and try out new things all the time.

    After that comes support. Mark’s pretty clear, your product will succeed or fail based upon how you handle support requests. He thinks that the development of a plugin inevitably leads to support tickets, and this needs to be factored in right from the start.

    We also get into the subject of pricing, and what Mark felt was the right place to pitch his plugin. Is the WordPress ecosystem guilty of expecting a lot from plugins at prices which are realistic? How much of the functionality, if any, should be given away in a free version, and how did he decide which features to charge for?

    Towards the end of the podcast, we stray into the plugin’s use of AI, and how Mark was an early mover in this area. What can be done with forms and AI, and does he see AI as a technology which is going to grow in the future?

    Useful links.

    WS Form LITE on the WordPress repo

    WS Form website

    OAuth

    Big Orange Heart

    GiveWP

    Newsletter Glue

    KadenceWP

    OpenAI

    DALL-E

    GPT-4

    WS Form Twitter

  • #74 – Ahmed Kabir Chaion on How to Find Your Place in WordPress Even if You Don’t Code

    Transcript

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case finding a place in the WordPress community as a non coder.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you, or your idea, featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today, we have Ahmed Kabir Chaion.

    As you’ll hear in the podcast, Ahmed has a genuine love of the WordPress community. He’s been an organizer at multiple WordPress events, including WordCamp Asia, the WordPress Accessibility Day. WordFest Live, WordCamp Santa Clarita, and the WordPress Translation Day.

    As if that were not enough, he’s also served as the co-organizer of the Dhaka WordPress meetup chapter, is a former Design Team rep, and a current Polyglots Team rep. Like I said, Ahmed is really engaged in the WordPress community, but how did all this happen? The podcast today focuses on Ahmed’s journey into WordPress.

    Given Ahmed’s involvement in the recent WordCamp Asia, we start the discussion there, talking about how the event went and what plans there are for next year.

    We then get into what the WordPress community is like in the city of Dhaka and Bangladesh as a whole. Technology has become a popular career option, and WordPress is playing a crucial role in that. We talk about how the community is growing, particularly through local meetups.

    The rest of the podcast is all about how you can find a place in the WordPress community no matter what your strengths are. Maybe you’re into writing code or SEO. Perhaps marketing or translations or more your thing. Ahmed lays out the multitude of paths that you can take to engage and give back to the project.

    You don’t need to feel you’ve got to be an expert. The project needs people working at every level, and maybe there’s work to be done which you did not know about. That’s certainly Ahmed’s experience.

    He tells us how we got started just by showing up repeatedly, slowly working out areas where he thought his contributions would be most valuable.

    We talk about some of the places Ahmed has frequented online, and some people he’s been most influenced by.

    It’s a lovely tale of a community member who is truly inspired to make the project better.

    In places, the quality of Ahmed’s audio is a little poor. But it’s more than listable, especially given how enthusiastic Ahmed is.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast. Where you’ll find all the other episodes as well.

    And so without further delay, I bring you Ahmed Kabir Chaion.

    I am joined on the podcast today by Ahmed Kabir Chaion. Hello, Ahmed.

    [00:04:08] Ahmed Kabir Chaion: Hi Nathan. How are you?

    [00:04:09] Nathan Wrigley: I am so pleased that we’ve got you on the podcast today. We don’t usually reveal about the technical gremlins, but we did have some technical gremlins, so much so that a previous podcast recording we abandoned, and we’ve come back today to try again.

    So firstly, Ahmed, really fully appreciate you sticking with the process and helping me get this podcast episode out. I really appreciate it.

    [00:04:32] Ahmed Kabir Chaion: Thank you, Nathan.

    [00:04:33] Nathan Wrigley: You’re very welcome. So you’re on the podcast today. We’re going to talk about open source contributions and who might do that, and how you might do that. And indeed, what you might do, whether you are a coder or a non coder.

    But Ahmed, just before we begin, we always typically ask the podcast guests to spend a moment just telling the audience about who they are, where they’re from, what they’ve been involved within the WordPress space. So may I ask you that question? Just tell us a little bit about yourself and how you relate to WordPress.

    [00:05:03] Ahmed Kabir Chaion: Absolutely. So my name is Ahmed and I’m from Dhaka, Bangladesh. I started my WordPress journey in 2009 for a university project. And then I shifted into my major, which was network security. I graduated from Central Queensland University in Australia. From 2010 to 2019, nine years, I was not involved with WordPress by any means, not even professionally.

    I came back to Bangladesh in 2016, and in 2019 when I switched my workplace, I joined a company called weDevs, from where I actually got involved into WordPress on a full-time basis. And I found that there are some voluntary options, opportunities, and scopes where people can go in and improve WordPress as it is.

    Now, not being a programmer or someone who likes to code myself, I was looking for ways to contribute to the project. And then, during the covid lockdown March in 2020, I started going through the handbook and other articles, blogs, tutorials that you can find in the internet possibly, to getting involved in the wordpress.org side of things.

    And slowly I started to see that it’s not always about writing codes and, going through the major release. And I started learning more about the Make WordPress Team. And then I found that there are many teams where I can get involved and I can start slowly be a regular.

    So I started with the marketing team, then went to documentation, and so on. Late 2020, one of the team reps for the design team suggested that I could also be a team rep. And being team rep did not have to be something that requires me subject knowledge or extraordinary skills, it can be something that I’m committed to giving back. And that’s where I basically fell in love with giving back to the community. Voluntary work for open source and so on.

    And gradually attended online WorkCamps. Became a co-organizer of my local WorkCamp, and Meetup as well. And then I organize online WordCamps. Just a month back, I was part of the organizing team for WordCamp Asia and so on. I feel like my journey has only started Nathan.

    [00:07:32] Nathan Wrigley: That’s great. We share show notes, so Ahmed has shared me a variety of different things that he’s been involved with, and really over the last couple of years, during the pandemic and obviously subsequently with things like WordCamp Asia, there’s a whole laundry list of things that you’ve been involved in.

    So we mentioned WordCamp Asia, Accessibility Day. You’ve been involved in WordFest Live, and a whole bunch of other things. There’s a great big laundry list. So, firstly, thank you. The project doesn’t move forward without people such as yourself. So we’re in your debt for taking so much on in the recent past.

    [00:08:07] Ahmed Kabir Chaion: Thank you so much. I guess recognition is something that motivates people, but personally I am happy to continue as much as long as I can, because I considered this as a privilege. That I’m able to give back to the project and also collaborate with many folks across the world. So I think it’s a privilege for me be able to give back.

    [00:08:28] Nathan Wrigley: That’s so nice. I want to digress just a little bit because of a couple of things that you said there. Firstly, I want to ask you about your experience at WordCamp Asia. It finished a little while ago. I’m not entirely sure when this podcast episode will go out, so there may be several weeks between it finishing and the podcast airing, but regardless of that. You attended, and by all accounts you enjoyed it.

    I’m just wondering if you could tell us a little bit about your experience there. You can talk about the organizational side, if you like, or just purely what you did, or how you enjoyed it. What you thought about it. What were your memories from that event?

    [00:09:06] Ahmed Kabir Chaion: Right. WordCamp Asia is the first flagship event within Asia, and the biggest WordPress event in Asia as well. As we all know, it was scheduled to happen in 2020, right before we had lockdown instructions and not have WordCamp Asia three years ago. With the hard work and effort for everyone, WordCamp Asia finally took place in Bangkok, Thailand.

    From an organizational point of view, I went through the application for becoming an organizer, and I was allocated to the contributor day team, which perfectly fit with my interest, passion. And, as part of the contributor day team, I was able to inspire many contributors through 11 live episodes that we did. We did some webinars on Facebook, Twitter, and YouTube live, and we were able to engage with contributors across Asia who would eventually, I believe about 50% or more actually showed up for the event.

    Even though we weren’t selling tickets for the WordCamp, we were getting lots of inquiries related to that because people wanted to come, and attend the biggest contributor day event in Asia. And successfully the first day of the WordCamp, which was 17th of February, we had 650 registered participants who were supposed to come up, and ended up having 700 plus.

    People were so keen to contribute. We had snacks and lunch allocated for registered participants. Some folks came to the door and said, hey, I just want to contribute. If you have a seat, let me take part. I don’t mind having snacks or lunch. I’m happy to just be here because it’s first time.

    For my contribution to the WordCamp Asia, I feel like myself, along with our team lead, Lia Kale, who’s from Nepal, and he has been the themes team rep for quite some time. We also had two other members, Yugi and Doji, who’s from Bhutan, and Lax, who’s from Philippines.

    So four of us actually managed the whole contributor day side of things. Outreaching to teams. Making sure we have representation, contributor table leads, and they have a plan. We contributed for about seven to eight hours on 17th of February. We received great feedback, good feedback from the participants, from the table lead, sponsors, anyone who came in said that they had a great time contributing and collaborating together.

    Even folks who were not from Asia gave feedback saying that it’s culturally vibrant, and it’s also fulfilling to collaborate together. So from that point of view, I feel like we had an excellent time.

    Moving forward to the next two days, 18 and 19, which is WordCamp Asia. We kicked off with Matts Asking Me Anything, more like fireside chat with Josepha being there as one of the co-hosts. That pretty much set the tone for the WordCamp, and we had excellent round of speakers, which people can go in and check from WordCamp Asia YouTube channel. All the sessions are still being uploaded, and information is there on the site.

    I feel that it was a much needed event and now that we have WordCamp Asia on the calendar itself, WordCamp Asia 2024, which will take place in Taipai, Taiwan is going to be a much bigger one. And even better one, because from an organizational point of view we will learn more than we actually accomplished in the past 10 months, 12 months, I should say. Started somewhere around this time last month of organizing. It’s been an experience that we want to relive again and again.

    [00:12:58] Nathan Wrigley: Oh, nice. I had quite a few chats with people who were in attendance that I know and the general feeling that I got from them, I didn’t attend, so I should probably throw that in. The general feeling that I got from more or less everybody that I spoke to was that it was quite a special event.

    They weren’t really able to capture why they thought it was special, but there was something going on at that event that they thought was pretty extraordinary. Maybe it was the fact that it was the first time. Maybe it was the fact that they were attending a country that they had perhaps not been to before.

    There was something there. I don’t know. But everybody that I spoke to really had something incredibly positive to say about it. So yeah, big congratulations to the entire team of people who pulled that off. Very much appreciated and looking forward to Taiwan next year.

    I want to just change direction just very quickly again before we get into the main subject, because in your introduction you mentioned that you are in Bangladesh. You mentioned Dhaka, I don’t know if you actually live there not. But I wonder if, for the audience listening, I wonder if you could paint a picture of what the word WordPress community is like in Dhaka or perhaps better yet, in Bangladesh in general.

    Be nice to kind of prize that open so that we can have some feeling for whether the software is being used and developed and talked about, and are there events that are happening over there? Really just a broad question. What’s the WordPress community look like in Bangladesh?

    [00:14:28] Ahmed Kabir Chaion: Yeah, it’s an interesting question. I’m going to try to paint my version of the picture about this, because there are three aspects. Aspect one is that WordPress and contributing to WordPress and open source is not fairly new to Bangladesh. It’s been there, but then again, everyone wants to be either recognized or have something as a return because of their recognition.

    I guess it comes from the fact that we are developing, and people want to spend most of their time in getting something back or being productive. So, contributing to open source is something that people does not take that positively because they want to spend that time for work or other purposes.

    Now there are communities and leaders within the community who encourage others, and it’s slowly, gradually building. I feel from 2020 onwards, since the lockdown happened, many people have looked back and utilizing their leisure hours, where they just want to do something more.

    They want to improve their skills. And from the point of learning new things, WordPress comes up simply because we have a growing community of freelancers, and the freelancer community has been there since 2010, 2011. And a major portion of our revenue, foreign currency revenue, comes from freelancers. Which is why software companies in Bangladesh do get many benefits if they’re bringing foreign reserves to Bangladesh, for example, dollars.

    So freelancers numbers growing. So they know WordPress for a profession. They use WordPress for their clients, for their different projects. Marketplaces have 80 to 90% projects related to WordPress. And this number fluctuates from now and then. But when it comes to contributing to WordPress Core, people aren’t aware because of another thing called communication skills.

    Which is something we are lacking for many years now. And I work with a lot of freelancers trying to train them with their level of English. I even work with companies improving their corporate communication business and formal writing, all of those stuff, since I was trainer back in Australia. And that experience came in handy when I started collaborating with the freelancer community in Bangladesh.

    So we have one organization called B D O S N, Bangladesh Open Source Network, and that was the primary driver of open source events and open source platforms. They had lots of events about Mozilla and WordPress. But as we got closer to the pandemic, it slowly decreased and pretty much non-existent this day.

    So the second aspect of your question is that people know about WordPress because we have seven Meetup chapters within the country, and Dhaka being the capital is one of the most active one, and there’s nothing wrong for me to say that it’s pretty much leading the efforts of community engagement for WordPress. Encouraging people to attend Meetup events. Letting people know that they can Host Meetup events, and in general sharing information about that, the knowledge share about that.

    So, Dhaka’s been inspiring Chittagong, then Barisal, Sylhet. These are different Meetup chapters within Bangladesh. And a result of that is actually WordCamp Sylhet scheduled for May 19th this year. So, in 2019, we had our first and only WordCamp in Bangladesh, which was called WordCamp Dhaka 2019. Now we’re going to have WordCamp Sylhet on May 19th.

    So I feel that it’s still a work in progress. So a lot of people still come to Meetups and say that this is their first time joining a Meetup. And we had about 275 people attending WordCamp Asia from Bangladesh only. So that brings in the third aspect of your question that we’re getting regular folks coming to the Meetups.

    I was fortunate to be able to host the first mega Meetup of the country, last year in November. I hosted a meetup with one of my colleagues, named Yasin Raman. I don’t know if he’s listening or will be listening. Shout out to him, because both of us organized an event with 170 people joining. We had five speaker sessions.

    It was around five hour event. We got sponsors luckily, and it was like a mini WordCamp. We got the feedback people coming back to saying, hey, you hosted a mini WordCamp. It was not a WordCamp, it was just a WordPress Meetup, and I was inspired by the South Florida Mega Meetup, posted by David Bisset. I got the idea that you could bundle and merge Meetup chapters and have a bigger event to give more people allocation for the event. Usually in our meetups, we get 50, average 50 participants, so having 170 plus was the next step for us to getting there.

    So to summarise, the answer to your question. The government acknowledges open source and WordPress is there. We have some initiatives, but that’s only for the companies and organizations, software developing companies and whatnot. B D O S N, as I mentioned, is still not that active. I feel there’s not enough contributors there. And when it comes to WordPress, I do see this particular release, 6.2, which is scheduled within a week and a half. So around 30th of March, we will have what per 6.2 release.

    I at least feel or expect and anticipate that we’ll have 50 plus contributors from Bangladesh itself. So that is a big number as well for us, because last time we had about 30 or even less. So, it’s going to a direction when we will have regular contributors contributing to WordPress, attending WordCamps, hosting events, and just carry it forward.

    [00:20:55] Nathan Wrigley: It really does sound like there’s an awful lot going on in your part of the world and a great deal of excitement and change and new people coming in and new events and a whole ground swell of new and interesting challenges arising. That really genuinely was fascinating. I really enjoyed that. Thank you for describing that in such detail.

    [00:21:16] Ahmed Kabir Chaion: My pleasure.

    [00:21:17] Nathan Wrigley: It would be, really interesting if anybody was listening to this who is from your part of the world who hasn’t reached out, maybe this podcast episode will get even more people, you never know, attending. That would be lovely.

    We’ll move on to the main thrust of our conversation today because the topic which we had designed for this podcast episode was all about non code contribution to WordPress. And I know that that’s an area that you are very keen on. You mentioned in your introduction that you don’t really classify yourself as a coder. But clearly from everything that you’ve said, you definitely classify yourself as a WordPresser.

    And so that’s how this conversation’s going to develop. I wonder if you could talk to us about your experience as to whether when you began dipping your feet into the WordPress ecosystem, did you sense that it was okay to be a non coder, or as I’ve heard many stories of people who, when they begin and they attend events, or they just start looking into community online, there’s this feeling that if you’re not into code, it might be more difficult to find your place.

    Now, I think as time has gone on, certainly in the last several years, I feel that’s less true in that we’ve figured out now that there are literally hundreds of different roles for people who don’t code. But I wondered what your experience was when you first encountered WordPress. Did you have that feeling of, if I’m not coding, I’m not sure I belong here?

    [00:22:45] Ahmed Kabir Chaion: Yeah, I did. The general consensus is that when you first join the make, making WordPress Slack, you land on the Core channel, and you see 30,000, I think it’s 40,000 now, 40,000 members in the Core channel. And the ones who are active around couple hundred people are talking about different code, sharing tickets of issues. It doesn’t feel like that anyone who doesn’t understand this can be a part of this. It gets intimidating.

    But for myself, when I first started, as I was going through Slack and exploring new channels, I found out there are teams called Marketing, Documentation, and, Polyglots and so on. So I started with marketing and I realized that you did not need to know coding or you did not have to write a developer field guide, or even you need to write a test report.

    And that got me thinking that, hey, that means it’s not always about writing code. It’s not always about customizing the front end of WordPress and so on. So I felt that, which usually we all feel when we first start. But lucky for me, I’m going to take some names because people have been nice to me and I was fortunate to have some guidance.

    There was Yvette Sonneveld, who’s currently working at Yoast, who used to be the then marketing team rep, who helped me a great deal around that time. There was Michelle Frechette, who I’m sure is a good friend of yours, and she’s been kind enough to spend many hours on Zoom. Not for my sake, but you know, different coffee breaks that used to be hosted in during the lockdown, marketing team used to have a monthly coffee break.

    I think they still do it. And I used to join those Zoom calls, which would be very difficult for my time zone, around 2 or 3:00 AM, midnight my time. But I would still stay up because I had literally nothing else to do, and people were in lockdown. So I would just attend there first three, four, or six weeks. I would just listen to what everyone else was saying.

    And as time progressed, and they were kind enough to just let us stay on the call and not speak a single word. So I give my thanks back to people. There are many names, I just cannot think of the names right now. But Milana, from documentation team, there’s John from documentation team. Alva Tucker from the marketing team.

    I feel like these are the folks who primarily set the tone for me and encourage that, yes. I’m not a programmer, and regardless of where I’m from, I can just give my time back in many different ways. And I started writing meeting notes, summary of a Slack meeting. I started posting those summaries.

    I started creating new agenda items, you know, talking to back and forth, different contributors. Even different time zones, some teams have meeting in different time zones. You know, there’s the EMEA, there’s this APAC one. So, going back and forth and trying to make sure the information is sustained across team communication is where I learned the most.

    So as part of the marketing team, I would attend other team meetings just to collect information from there, which we can then repurpose or re-share with other teams. These are ways that I got involved. And then jump to the documentation team. Like I said, Estella Weather. We have many other, I just can’t think of the names and I don’t think I’m being fair to them. These names need to be shouted to.

    Then I saw this opportunity. Well, there was this post before a major release, there’s a call for release squad members. You could just raise your hand and say, hey, I want to be part of this release squad. And after I became a core contributor for the first time for 5.6, I thought, okay, I’ve become a core contributor without writing a code. I can maybe do something even bigger.

    And if I just share this with the audience that what I did was I tested an issue that was reported many years ago. I replicated the issue in different operating systems and then I took some screen recording. I wrote some feedback. That was it. I became a core contributor and that got me thinking that I could do even something bigger. So I raised my hand to become a release squad member. And these are names that I cannot forget. Jeffrey B. Paul, who works for 10up. There’s JB address and there’s Peter Wilson, who’s from Australia.

    These are three folks primarily who inspired me to start working, or even contribute to the trials team for core releases, major releases. And I got mentorship from these three folks who just said that you don’t need to be a programmer. You can listen to the discussion of the programmers on Slack. Summarize it, and the programmers can continue their discussion.

    So what I used to do, I used to sit in front of my computer for one hour on a dedicated time schedule. The developers from different parts of the world would show up, or a ticket would be raised, and everyone would look into the ticket and share their feedback and ideas.

    Sometimes one ticket can spend an hour. Sometimes each ticket can be two minutes, three minutes long discussion. My job, my role was to summarize everything, document it, and making sure it’s passed onto the next meeting. Or, more importantly, update each ticket with what to do next, some recommendation. Sometimes I would do testing as well. And that’s how I found my place.

    I feel like I’m good at doing that. I’m confident at finding years old tickets, making sure we triage them. These are stuff that took me to the next level and I’m ready to give my time back again for WordPress 6.3 release squad.

    [00:28:59] Nathan Wrigley: That’s amazing. Such an interesting story and unlike one I’ve heard before actually. So a core contributor, but no code in sight. But nevertheless a very important set of roles that you were describing there. I wonder, you’ve obviously thrown yourself into this. In other words it does sound like it’s become an incredibly important part of what you do, and I wonder if you have any thoughts for people who really really maybe don’t have the time available that you do? Are not quite sure.

    They don’t see that they’ll probably ever be as keen as you seem to be. Do you think there’s a place for them? Is it more a case that if you are willing to really go the extra mile then these wonderful things can happen? Or is it the case that people who can just contribute perhaps a few minutes a week are still welcome and needed?

    [00:29:50] Ahmed Kabir Chaion: In short both. But for this to be meaningful and for someone to be satisfied about what they do, you need to go the long, longer path. If you are keen to learn something new. If you’re interested in finding out more and tap into the unknown, then WordPress is a beautiful prospect. I feel every team that I tap into, I learn something new.

    Currently, I’m collaborating with the training team and they have this project called Learn WordPress, which is going to be an amazing thing in a couple of years. It’s already there with many different languages of workshops, tutorials, and information about WordPress. Not just WordPress as a platform, but more like different aspects of WordPress.

    And, even as a programmer, there are different sides of programming. I’m not an expert, but I’ve noticed that some people like to do certain things. So there are components within WordPress. So if a programmer is interested about a particular component, they can start working on that.

    And I believe there’s 30 plus component with each of them having one to five, sometimes ten, component maintainers who take care of those components, which make sure that WordPress is equipped with everything new and not falling back.

    [00:31:09] Nathan Wrigley: It is truly remarkable, the depth and breadth of WordPress. So it’s kind of interesting. You’ve talked about the fact that you’ve dipped your toes into all sorts of different channels in WordPress. You’ve talked about marketing. You’ve talked about documentation and so on. I wonder, for people who are listening to this who are new to WordPress, I don’t know if you’ve got a list available or in your head, I wonder if you can summon up the range of different topics or areas within WordPress that people could become involved in?

    [00:31:39] Ahmed Kabir Chaion: Sure. so there’s two set of common topics or checklists that I usually share. We had our latest Meetup just couple of days ago, and I was discussing this topic with a few of our new contributors. So one fact is that if someone’s willing to join the local Meetups, they should start there. That should always be the first step. That gives so much motivation and encouragement, and you can engage with a lot of people.

    And for those who are able to attend those Meetups, they can start finding WordCamps nearby. I don’t know if everyone loves travel, but I love travel and it can sometimes do a positive change for you. So traveling blended with WordPress is a beautiful thing. Unless you experience it, you won’t be able to know what I’m talking about.

    And the second thing is for those who does not want to go to the Meetup. For them, they can always go through the make.wordpress.org site. There are different teams. Just skim through and search for the team that feeds them most, or appropriate team. Find it and then go through that team’s handbook. Most of the teams these days have at least a workshop or tutorial within Learn WordPress. So if you want to contribute to WordPress org, you can check Learn WordPress first.

    Slowly create a WordPress profile and then join the WordPress Slack. As soon as you are able to join a channel, start finding if there is a time which is convenient for you in terms of that team’s meeting. Because team meetings are essential for you to be directly involved with the project. Some teams have weekly meetings, some teams have biweekly, others have monthly meetings. So it’s not that difficult.

    You don’t need to attend the entire meeting. Just stay up to date about your team of interest. About the agenda. What is the focus right now? What kind of work, different work groups are there. Try to tap into a work group. As soon as you are part of a work group, you will know about the details and the current stuff that’s in the pipeline for WordPress. And that can motivate a lot of people.

    And for those who are programmers, they can easily just go to the Core team. And there’s many different sub-channel and sub-teams of Core. There’s Core test. There’s Core performance. There’s WPCLI and many more. I’m just sharing some of the names from the top of my head, because that’s not my strong suit, but there are about six or seven different key teams or sub-teams within the Core team where you can get involved in.

    And I’ve always noticed among contributors, if there’s anything that is within the sweet spot of their passion and interest, it gives them a better result. So, finding that is critical for someone, when it comes to going the long run and sustainably contributing for many years.

    [00:34:44] Nathan Wrigley: You mentioned in the show notes that you had some resources to share. Now, it may be that you’ve just done that, and that was the list of things that you wanted to talk about. But I do want to give you an opportunity to share that list if indeed there were other things on it that you hadn’t yet mentioned.

    [00:35:00] Ahmed Kabir Chaion: Yep. I just want to add a name, Sam Munos. I think she works for WP Engine, and is the community developer relationship manager. Apologies if I got her designation wrong. But I have seen her in the documentation team and coming in and always contributing. And she’s the one who inspired me to talk about, or dive deep into this topic.

    I read one of her articles in Torque Magazine. It was published in August, 2002. The title of the article said, no code WordPress contributions matter. And since I read that article in 2000, I got to think, hey, my contributions matter too. Because for the better part of 2020 and 2021, I was simply just contributing as a no coder.

    But now I see people talking about it, and I think Torque Magazine wouldn’t cost anything if that wasn’t substantially important. And I think that article, since I read it, I’ve shared it with at least 15 to 20 people. Just so that I could encourage them to come and contribute to WordPress.

    So when it comes to the resources, there is a lot of resources out there aside from Learn WordPress. But I feel like just following a few folks in Twitter can do the trick for now, for anyone starting. Sam Munos is one of them who I believe is going to be a great advocate in the coming years for non code WordPress.

    [00:36:31] Nathan Wrigley: Thank you so much. What I’ll say is that when we finally click the button to stop recording, I’ll allow us the opportunity to collaborate on the show notes that hit the WP Tavern website. And there may well be things that Ahmed would wish to add, names that he wants to mention and so on, that he hasn’t managed to get together for this show. And I’ll put those in the show notes. So if anything does occur to you in the next days or weeks before this episode goes live, hopefully we can add those in as well.

    We’ve talked a little bit about WordPress events. We’ve obviously, the whole going back to doing things in person is probably one of the most interesting things in the WordPress space. You know, it is fabulous to get in the same room as all those people. But the vast majority of what you are describing is taking place online. And I’m just wondering again, the description for those people who’ve never contributed before. What kind of processes are people going through?

    You know, it can be a bit intimidating joining a Slack channel. But is that the kind of place where all of this happens? Do you need to be following track tickets? Where do you find yourself online? Where do you collaborate online to make this happen?

    [00:37:48] Ahmed Kabir Chaion: I think that’s the question that I hear the most. And you are right on the money with that question. For anyone who has heard about my story and coming back to me, hey, what’s the right place? I always refer them to the Core channel for Making WordPress Slack. However, if you are not someone who wants to go through every single message on Slack, you’re not alone.

    You can just go through. Check the weekly article. There is a dev chat, that is being published each week after the meeting that happens on Slack. You can simply check that article. And staying up to date with what’s happening, weekly basis. The Core channel, or the p2 blog for making WordPress is more than enough. Because anything important to the release itself, or any important track ticket is always circulated back to the Core channel blog as well. So I think that’s enough.

    But then again, if you don’t want to do that either, I feel like just attending online events such as online WordCamps. There’s WordFest. Whichever event that you can find. WordPress Accessibility Day. I’m also going to be part of the organizing team for this year as well.

    We’re going to announce the dates very soon. It’s going to be in September. That’s also another event that you should look into. It’s a 24 hour event about WordPress and accessibility. So these are events that are options out there. And you just need to find the option that speak for you, that’s most fulfilling and giving back to you. And also consider yourself important too, when you are giving back.

    [00:39:28] Nathan Wrigley: Yeah. It’s interesting you described a period of what you might describe as lurking at the beginning. In other words, you dropped into certain channels and just observed. And I guess that’s probably some good advice. If you’re not sure where to go. Just go there. Hang out. Read the messages. Engage if you wish to. But if you don’t wish to, just watch and see what happens.

    And if a certain channel or aspect of WordPress doesn’t seem to be clicking with you, there’s always the opportunity to go and start that process of lurking again in another channel. And I would imagine that at some point you will stumble across something which is the best fit for you.

    [00:40:09] Ahmed Kabir Chaion: Of course, and I keep on repeating these to folks who I collaborate to that, remember your skills, or strength, or things that gives you satisfaction. And just keep your eyes and ears open. If you see something that clicks with you, just raise your hand. I’ve had 10 people coming back to me saying that, hey, don’t worry, we are here. I received private messages. The first step is to raise your hand, and that’s the bravest step you need to take. I did that, and I’m not regretting that.

    [00:40:44] Nathan Wrigley: Nice, that’s great. Ahmed, time is precious, and so we’ll start to wrap it up. But before we do that, I want everybody to be fully aware of where they can find you. If there’s people listening to this who have been inspired and would like to use your expertise, maybe talk to you one-to-one, email you or whatever it may be. I’ve got this feeling that you are going to be able to persuade quite a few people who are erring on the side of caution to dive into WordPress. So with that in mind, I wonder if you wouldn’t mind just sharing some of the places where you hang out online, where you are most likely to be found.

    [00:41:21] Ahmed Kabir Chaion: Absolutely. I’ve got my Twitter handle, which is c h a i o n zero seven. My last name. But that’s pretty much the handle you need to remember. LinkedIn, it’s Twitter. Everywhere I’m available using that handle. Also, I attend the Polyglots weekly meeting. So if you are a polyglot, if you want to translate WordPress into your own language, which you can always do, you can come to the Polyglots channel and I’m pretty much active there, since I’m the current team rep, or one of the current team reps.

    [00:41:55] Nathan Wrigley: That’s absolutely fabulous. Hopefully Armed, we’ll get some people coming in your direction. I really appreciate you coming on the podcast today. It’s been a real pleasure talking to you about your experience in your part of the world, and more broadly with WordPress. Thank you so much for joining us today.

    [00:42:12] Ahmed Kabir Chaion: Thank you so much, Nathan, and I think, what you’re doing can inspire hundreds and hundreds of more contributors. I hope to hear from you in the future and hopefully meet you in person in one of the WordCamps.

    [00:42:24] Nathan Wrigley: That would be indeed very lovely. Thank you so much for joining us.

    On the podcast today we have Ahmed Kabir Chaion.

    As you’ll hear in the podcast, Ahmed has a genuine love of the WordPress community. He’s been an organiser at multiple WordPress events, including WordCamp Asia, the WordPress Accessibility Day, WordFest Live, WordCamp Santa Clarita, and the WordPress Translation Day. As if that were not enough, he’s also served as co-organiser of the Dhaka WordPress Meetup Chapter, is a former Design Team Rep and a current Polyglots Team Rep.

    So, Ahmed’s really engaged in the WordPress community, but how did this all happen? The podcast today focuses on Ahmed’s journey into WordPress.

    Given Ahmed’s involvement in the recent WordCamp Asia, we start the discussion there, talking about how the event went and what plans there are for next year.

    We then get into what the WordPress community is like in the city of Dhaka, and Bangladesh as a whole. Technology has become a popular career option, and WordPress is playing a crucial role in that. We talk about how the community is growing, particularly through local meetups.

    The rest of the podcast is all about how you can find a place in the WordPress community no matter what your strengths are. Maybe you’re into writing code, or SEO. Perhaps marketing or translations are more your thing.

    Ahmed lays out the multitude of paths that you can take to engage and give back to the project. You don’t need to feel you’ve got to be an expert. The project needs people working at every level, and maybe there’s work to be done which you did not know about. That’s certainly Ahmed’s experience.

    He tells us how he got started just by showing up repeatedly, slowly working out areas where he thought his contributions would be most valuable.

    We talk about some of the places Ahmed has frequented online, and some people he’s been most influenced by.

    It’s a lovely tale of a community member who is truly inspired to make the project better.

    In places, the quality of Ahmed’s audio is a little poor, but it’s more than listenable, especially given how enthusiastic Ahmed is.

    Useful links.

    weDevs

    Make WordPress

    WordCamp Asia

    WordPress Accessibility Day

    WordFest Live

    BdOSN, Bangladesh Open Source Network

    WordCamp Dhaka

    Learn WordPress

    WordPress Slack

    No-Code WordPress Contributions Matter

    Ahmed’s Twitter

  • #73 – Ryan Welcher on Using the create-block Tool to Quickly Scaffold a New Block Plugin

    Transcript

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case how a block plugin creation can be speeded up with the create-block tool.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the podcast I’m keen to hear from you, and hopefully get you, or your idea, featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today we have Ryan Welcher. Ryan is a developer advocate sponsored by Automattic. He has been developing with WordPress since 2009. And before becoming a developer advocate, worked for agencies large and small, and as a freelancer.

    If you’ve been using WordPress for any length of time, you’ll have come across the new paradigm for content creation, blocks. Every part of your website can now be created and amended as a block. Pages, posts, text, images, headers, footers, navigation, and more.

    This has widened what’s possible for those who don’t want to mess around with the code of their website. You can add in blocks for almost anything. And change how it looks and behaves from within the block editor interface.

    This is an excellent move forward, but there’s still an impediment for non-technical people because creating a block of your own is difficult. If you are able to use the selection of blocks that ship with WordPress Core, or you can find a third party block which does what you need, great. But if you need something specific, you’re going to have to create your own block solution. And that can be hard.

    Ryan is on the podcast today to tell us about the create-block tool. And how it can make your pathway towards block creation a little easier.

    We start off talking about Ryan’s background and how he became interested in WordPress.

    We then move on to how he thinks that the adoption of blocks is becoming more widespread given the maturing of tools and learning materials available.

    The conversation then turns to how the create-block tool can help you scaffold your blocks. It’s not a tool which is going to build the blocks for you, but it will help you set up the environment and build process, which you need to get started. Really it’s all about saving you time and effort on things which don’t really you get you building your blocks, but which you need to do that work.

    We discuss what you can expect from the create-block tool, and the prior knowledge that you’ll need to have once the tool has you up and running. What level of expertise do you need, and is the tool under continual development?

    We spend a few moments talking about the live streaming which Ryan does each week in which he lived code solutions to view as block-based problems.

    If you’ve thought about creating your own blocks but have been put off by the technical barrier, this podcast is for you.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast. Where you’ll find all the other episodes.

    And so without further delay, I bring you Ryan Welcher.

    I am joined on the podcast today by Ryan Welcher. Hello.

    [00:04:29] Ryan Welcher: Hello. Thank you for having me. Super excited to be here today.

    [00:04:32] Nathan Wrigley: I’m really, really happy to have you on the podcast today, because I really need to learn what it is that you are going to be talking about. We’re going to be talking a great deal about the Create Block Tool, how it works, what it does, how to make it come onto a local computer near you. But before we do that, I wonder Ryan, if you wouldn’t mind spending just a few moments telling us a little bit about yourself, your backstory, your relationship with WordPress, who you work for, all of that’s good stuff.

    [00:05:00] Ryan Welcher: Yeah, so I am a developer advocate. I’m sponsored by Automattic. So I’m part of the five for the future, giving back to the open source project that is WordPress. I’ve been a developer since about 2004. I started doing flash development. I don’t know if anyone remembers flash development, but I started doing that. In 2009 I was introduced to WordPress and I haven’t looked back.

    Since then I’ve worked at, I was a freelancer. I worked at small agencies, large agencies, shout out to 10up, which an amazing place to work, I love that place. Yeah, and so I’ve just found my way into Dev Rel, which is a very, very fun and exciting and challenging, and way different than what I was doing two years ago. But it’s been great.

    [00:05:41] Nathan Wrigley: Can I go a little bit off piste, against the flow of what the conversation will be about? Could you just tell us a little bit about the way that that job works? So you are sponsored by Automattic, is that a full-time thing?

    [00:05:52] Ryan Welcher: It is. I work on a team of Dev Rel, of developer advocates, and our job is to appear on podcasts, speak at conferences, create awareness and work on documentation and do all this sort of stuff. But, sorry, yeah, I cut you off.

    [00:06:04] Nathan Wrigley: No, no, it was really just, I’m curious as to how that role is advertised. Was it something that you saw in like a WordPress space, and you applied for it? And also who is it that decides what your roster of work is? Do you have autonomy there or is there a panel of people that you have to report to and so on?

    [00:06:24] Ryan Welcher: Those are great questions. So it was a role that was advertised. I saw someone mention it, and I think the WordPress Slack, the Make Slack. I applied and went through the process there. As far as the work that we do, it’s kind of a mixed bag. We do have a fair amount of autonomy. This is a newer team. There’s six of us for the entire internet, so. Sorry, for 43% of the internet. So there’s a lot of work to do.

    We have a focus on improving documentation. That’s kind of our number one focus at the moment. But, there’s a lot of smaller projects as well. I try to maintain the Gutenberg Examples repository, which is a GitHub repository that shows examples of working with blocks and some of the various things that you can do with Gutenberg, like a custom admin page that interacts with the data stores in Gutenberg and things like that.

    So, I was just at WordCamp Asia, which was an amazing experience. I wasn’t speaking, but I was meeting with lots of developers and just kind of like schmoozing. I get to schmooze professionally now, which is a lot of fun.

    [00:07:16] Nathan Wrigley: That’s amazing. I do wonder since Gutenberg dropped several years ago now. I mean, it really is, it has been going for many, many years. But there really was a fork in the road for WordPress there, and there was a little bit of tension. Some people didn’t see the purpose of Gutenberg and ultimately blocks. And I do wonder if roles like yours became more important after that. Do you feel like a need to message and get the word out and educate more after Gutenberg dropped?

    [00:07:49] Ryan Welcher: I think yes. I also think that the tech industry, I mean, there’s always been developer advocates. I remember I went to a flash conference years and years and years ago, and I saw someone speak there who was, what were they called at the time? A platform evangelist for Adobe and was basically doing Dev Rel stuff, like showing what you can do with flash and the new features and cool stuff. So it’s been around.

    I think now people are really starting to see the benefits of it. Especially when you have a large community like WordPress. There’s so many people. And having people who can help, you know, the education piece. And there’s a lot of yelling into the void without people like me and our team to hear what you’re saying. Like, you know, the documentation needs work. Okay, well someone needs to work on that. Now that’s my job to work on that.

    So I definitely think that there’s, there’s benefits to Dev Rel in any industry for sure. But I think, to an extent, when 5.0 came out, I think that sort of showed the need for someone to come in and say, hey, you know, do you need help there? Or like, have you heard about this tool? Or what’s path of least resistance to move from a short code to a block? All those sort of things. So I think yes and no. I think it’s just overall, having a dev team for the open source project that is WordPress is a great idea to gather feedback and help and just help. Full stop.

    [00:09:06] Nathan Wrigley: I think whether it’s as a result of endeavors from people like you, or just the passage of time. I get the feeling that in the year 2023, the message is really getting through. It seems like the inertia against using blocks seems to be dissipating. I really don’t seem to be exposed to too many YouTube videos or people on Twitter moaning too much about that anymore. Moaning is probably the wrong word. I should probably reclassify that, questioning it.

    [00:09:38] Ryan Welcher: No, I think it’s a very accurate word.

    [00:09:40] Nathan Wrigley: So it feels as though we are at an inflection point. That there’s enough time that’s passed. There’s enough projects out there. There’s enough people that have released resources and commercial products around the block space.

    It kind of feels like it’s moment has really arrived.

    [00:09:57] Ryan Welcher: I agree, yeah

    [00:09:59] Nathan Wrigley: Maybe moving from a position now of teaching people that it exists and it’s an option, into teaching people how to use it and get the most out of it?

    [00:10:07] Ryan Welcher: Yeah, I would agree with that. I think since 5.0 the block API has matured, and has stabilized. There was a couple of releases where every release, the function that you called to actually register a block in php, its name changed, and its function parameters changed.

    And then there was like one version, and then the next version was a slight variation but the next version was the same name as the first version, but with different parameters. So there’s some confusion there. And you know, with the introduction of block.json, it’s the json file that describes what your block does and what its functionality is. Having those pieces sort of stable and consistent have really helped the adoption of blocks and custom blocks.

    I think also, and this is a perfect segue into what we’re talking about today, the tools like to Create Block Package that we’re going to talk about introduced to best practice and showed people, how do I structure my blocks?

    So when I was at 10up, I was at 10up when Gutenberg came out. And we spent a lot of time, the company spent a lot of time trying to figure out, trying to navigate how is this going to work for an agency? How do we build these things? What files go where and things like that.

    And so that’s a huge amount of cognitive dissonance. When you’re trying to figure out a new api. When you’re trying to figure out a brand new paradigm. And then you’ve got to figure out, well, where do my files go? A tool like the Create Block Package just shows you where the recommended structure is. And then that takes away a lot of the guesswork, and then everything becomes consistent at that point.

    And then if I’m working on a project that someone else has worked on, the files at least are in the same place. And, I think the maturity of blocks and the block API has really left a lot of the people who just didn’t like it kind of behind.

    [00:11:39] Nathan Wrigley: Okay, so given that we don’t really have any accurate statistics on who’s using blocks. What proportion of the 43% of the web that’s using WordPress have moved over to blocks, or perhaps are sticking with the page builder that they’ve been using for the last several years and so on. Given that we don’t really know that, what is the elevator pitch for blocks really? What are the small things that you can mention on a podcast in a short space of time, which really nail your colors to the master and say, okay, this is the promise of blocks? This is what blocks can deliver. This is why it’s new, and why it’s worth looking at.

    [00:12:14] Ryan Welcher: That’s a great question. I think that blocks offer, well, first of all, there’s no theme or plugin lock-in. So that’s a big concern with, take the example of a freelancer that is hired to build a site and the client is non-technical, but they want to be able to manage their own content.

    So, you reach for some of these page builder tools, and now once you’ve reached for them, you’re locked into them. That’s not a criticism, but that is inherently one issue. So with blocks you don’t have that. Your blocks are part of core and you could still suffer a bit of lock-in, if you went with a very bespoke sort of block set or like a block suite or something, but there’s definitely some benefits there. You don’t have a lot of the overhead or any of the overhead that come with some of the larger, page builder plugins, just because they have so many features.

    And so there’s some load considerations there. I think it changes the way that you can look at your content. This is a bit more of a philosophical question, but, so historically when we built a site, we had a title for post content. We had the content, which was like the classic editor. And then we had post meta, and you know tags and categories. But if we wanted to store an extra piece of information with a piece of content, there was really only post meta available to us, because the template that was being shown for the front end that would represent that piece of content ,was controlling the layout.

    And so we had to store, let’s use an example of an author byline. Say we wanted to have guest authors on a site. So we wanted to store that author name. Well, on the template side you would use get post meta, the function, to get that piece of information and, and display it in your template.

    Well, now we can do that all with blocks, because our template is the editor, and the way it looks is basically represented almost one-to-one in the block editor experience and the site editor. So you have this question of, do I need all this post meta now? Now I can just store it as a block attribute, and move it around and do what I need to do with it. So I think there’s lots of good reasons to use blocks. That’s a few of them maybe.

    [00:14:09] Nathan Wrigley: Yeah, that’s great. Thank you. I guess the primary issue is that using something like a page builder, whether or not it’s got bloat or whether or not you’ve got the lock in and all of that, is that it’s relatively straightforward. You just click some buttons essentially. Drag things onto the canvas and you’re done. In Gutenberg we’ve got some core blocks, and increasingly you can really start to lay things out with group blocks and cover blocks and things like that. You know, you really can start to finesse the overall design.

    But if you want to do anything bespoke, in other words, if you want to create a block which does something that you wish to do, something new, something interesting. Then you’ve got to create that block. And the barrier to doing that I feel is quite high. I wonder if you’ve got any thoughts on that? Whether or not the creation of blocks is still in the domain of, how to describe it? You’ve got to have a certain fairly high level of understanding of all sorts of technologies to make these blocks come into existence. Or do you?

    [00:15:12] Ryan Welcher: Well, you do and you don’t. It’s kind of like, it’s the classic developer question, you know. It depends, is always the answer. Whenever you ask a developer something, it’s always, well, it depends. But, I think yes. You do need to have a certain amount of information. But take blocks out of the equation. If you wanted to make a bespoke WordPress theme, with custom templates, you still need to have a certain level of development experience and a certain level of prowess in php, html, css and things like that.

    Now, that’s not to say that the barrier to entry hasn’t been raised. Because when I learned WordPress in 2009, I could just copy and paste everything I did into a theme and it worked. Now we’re with blocks. We’re looking at, build processes and learning some JavaScript frameworks in React, some knowledge there. So there is, there’s definitely some things to learn.

    Now, there are some tools that can help. Again, this Create Block Package that will kind of get you started and get you a basic scaffold of a block, that you can just then change and add your flourishes to.

    I think in general, web development is more complicated than it ever has been. I mean, that’s maybe because I’ve been doing it for a long time and I’m an old man who fears change a little bit, maybe. I don’t know. But I think that knowing JavaScript and Matt said, you know, learn JavaScript deeply, and it’s true. I think I felt that pain when I was, starting to work in Gutenberg. I’m a php first developer. That’s what I learned. I did a little bit of JavaScript, but not a lot. Learning these new concepts was hard. But, I think it’s well worth it.

    And I think you can do things where you don’t need to know, you don’t need to be an expert in React. You don’t need to be an expert in Webpack and build process. You don’t need to be that level. If you choose to be that level, you can, but you can do some pretty complicated blocks, with sort of a base understanding of some of the pieces that you need to put together.

    And I think part of my job is to help people navigate that stuff. I’m a big proponent of the Create Block Package. I’ve worked on the package. I’ve helped to add features that developers have asked for to make life easier. One big feature was the ability to have multiple blocks be part of the plugin that is generated when you run the package.

    So I think there is a barrier to entry, but I think it’s mitigated by, like, you don’t need to be an expert in all the things. You don’t even need to really understand the build process, for example. It’s provided, and it’s just run a command and just know that this command does this and this command does that. And really, if you don’t want to look under the hood, you don’t have to. It’s going to work for you.

    [00:17:30] Nathan Wrigley: We’ll get onto the Create Block Tool in a moment, if that’s all right. But just one last question around this whole education piece and learning about blocks. It feels that there’s a real concerted effort now to create learning materials. There’s obviously learn.wordpress.org, and a whole bunch of other things.

    I see a lot of videos being created in amongst the community. People like Jonathan Bossenger and Anne McCarthy and so on. And I’m just wondering if you, well, firstly, if you feel that that’s the case, if the education piece is a lot better now than it was when you were trying to learn at 10up? In other words it’s less of an uphill struggle because you’ve got somewhere to turn to.

    [00:18:09] Ryan Welcher: So much less, yeah.

    [00:18:11] Nathan Wrigley: So let’s do that one first. Yeah.

    [00:18:13] Ryan Welcher: Absolutely. I think, yeah, you’re right. I mean, I think that when Gutenberg came out, there was no real pragmatic, like practical, how to use this information. Because it was a new thing and there was a lot being changed and people didn’t have the resources.

    They didn’t have the knowledge to build the resources. Now we’re four years in now, and that’s obviously built up. The folks that learn.wordpress.org doing a fantastic job. Jonathan’s stuff is great. I’m going to shamelessly self-promote here. I stream every Thursday at ten thirty Eastern on Twitch, where we do block development live. and I put that on my YouTube channel. And I’m not the only one. I’m sure there’s, there are people that are putting out content that is up to date and accessible and easier to figure out the things that you need to do.

    Now, there’s always going to be gaps in that knowledge because the APIs are still evolving, and every time there’s a new release to the plugin, the Gutenberg plugin, there’s new features and things like that. But yeah, I think now compared to when 5.0 came out, I think there’s a lot more really good information out there.

    I’m finding that there’s older information that hasn’t been updated. That’s one of the pitfalls of the writing a tutorial on your blog post or creating a video or doing whatever, is that it’s sort of a snapshot in time of the APIs. And so it’s there, but then there’s, well, hey, did you know that there’s this new way of doing whatever it is that you’re doing that’s a little bit easier, you know, faster, better, smarter, or whatever, right?

    [00:19:34] Nathan Wrigley: Yeah. Going back to your shameless plug. Could you tell us a little bit more about that? So you say you go live, every Thursday, and we will get from you the URL and will post it into the show notes. Do you have an agenda for that? Do you know what you’re going to do in advance? Or is it driven by who shows up and what questions they want to be answered?

    [00:19:53] Ryan Welcher: it’s a bit of both. I’ve been doing it now for about a year and a half. I’m on Twitch, which is an interesting experience. So I live code. I usually show up with some kind of agenda. Like, for example, right now, last few weeks, every other week I do a stream on the new features that have been released in the Gutenberg plugin.

    If you’re not aware, the Gutenberg plugin is on a two week release cycle. So every two weeks we get a new version of that plugin, and then all those versions get rolled up and released into the next version of WordPress Core. I go through the release posts on make.wordpress.org, and we call out some of the more developery refocused things like, a new component is added or a new whatever. So we do that.

    The off weeks, I usually build something. Like right now I’m building a block that integrates with OpenAI to generate images. But the images that are being generated are terrifying because I keep doing like people laughing. I don’t know if you’ve ever seen OpenAI generate people’s faces. It’s the scariest thing I’ve ever seen in my life. Have a lot of fun doing that.

    I’m actually going to be doing one and I haven’t done this yet, and again, sorry for the shameless self-promotion here, but in a couple of weeks I’m going to be doing a bring me your block development issues stream, where I’m hoping that people will submit these problems that they’re running into and I’m going to try to see if I can kind of like fix ’em live. And we’re going to stream that and see how it goes. It’s going to be wildly successful or it’s going to be crickets the whole time. I don’t know. That’s usually the only two extremes you get on live.

    [00:21:19] Nathan Wrigley: I do like the idea of a, like an open surgery in a way. Where people can show up and give you their problems and presumably the further in advance they can give you the problems, the more of a chance you’ve got of actually solving them. But that’s a really interesting idea and an excellent way to help educate people live, watching somebody else do it, not just on a forum or an email chain. Actually seeing it happen and get an explanation for why you’re doing things and possibly even watching you make mistakes along the way and having to fix your own things, yeah.

    [00:21:48] Ryan Welcher: If anyone comes to my stream, you will watch me make mistakes Yeah, I can’t type when people are watching. There we go, that kind of sums my stream up. But yeah, it’s a lot of good fun. And we have pretty good community of people who hang out in the chat and discuss things and answer questions and help me. There’s one guy, I always make fun of him because he shows up and saves the day every time if I’m running into an issue, he’s like, here’s your code. And he just pastes it, and I’m like, oh okay, great. So now we can move on because Kevin saved my stream. So shout out to Kevin.

    [00:22:14] Nathan Wrigley: That’s a, lovely community feel to it though, isn’t it? There’s something really nice about that. But definitely, before we hang up on this call, I will get the location for that and we’ll post that into the show notes. So if anybody wants to go and hang out with Ryan on a Thursday and watch him live code and possibly take your own troubles and problems and share it with Ryan, yeah, that would be a really amazing enterprise.

    Okay, let’s get onto the, what we probably should have started talking about a while ago, but never mind the Create Block Tool or the Create Block Package. So one of the problems that you highlighted right at the beginning when I said, what makes blocks difficult, is you talked about the tooling and the requirements that you need just to get started. So describe the problem that the tool is solving.

    [00:22:58] Ryan Welcher: Sure. So if you want to build a block, there’s a number of ways that you can do it. But if you wanted to build a block using React and JSX, which is the HTML extension, the JavaScript that React uses, you need a build process. You need the ability to take your JavaScript code and transpile, it’s a fancy word of saying turn it into something else, into JavaScript that the browser can read.

    So to do that you need a build process. And so a build process can be very complicated. Now, build processes have been around forever. If you’ve heard of Grunt, or you’ve heard of Bower. There’s a few, so what we use is Webpack. Now Webpack can be extremely daunting to set up and deal with. The story that I always tell was the first React app I ever built was when I was working for an agency, and they wanted to use Webpack and we went to the Webpack documentation page and all it said was work in progress.

    And, it was very funny because the only comment on it was a giant picture of that meme of Picard with his arm stretched out going, why? I wish I had a screenshot of that because that’s best story ever. Anyway, so that’s your first issue.

    Your second issue is how do you even structure blocks? There’s a number of files and a number of pieces to a block. And, you know, if you put 10 developers in a room, those 10 developers will have 10 different ways of scaffolding this. So that was always a bit of a problem as well. So what this tool does is it solves those problems first.

    So it installs your build process, the one that is actually used by the Gutenberg project as well. It’s maintained, it’s got a million little features and you don’t have to worry about that anymore. And then it also will scaffold the files for your block and put them, give you the names, give you all the files, give you a starting point.

    When you run the scaffolding tool, it will prefill a lot of the, sort of, details of your block and give you the starting point. And it bundles it all up inside of a plugin, and so it’s a WordPress plugin that you can just enable and it installs all the dependencies and it even runs the build process. So you literally run it and then you press activate inside your plugin screen, and then you have an active block.

    That takes away so much guesswork and so much busy work of having to like, figure out the naming of things and add files. It doesn’t sound like a lot, but if you’re building 20 blocks, and you have to like, copy and paste all your files and go in and rename everything, that can take a lot of work.

    [00:25:10] Nathan Wrigley: Yeah, I can well imagine how much time that’s saving. Are there any constraints about where you can install this? So, currently I’m on a Mac. I presume that we’re all good to go there. What about Windows, Linux?

    [00:25:22] Ryan Welcher: The only thing that you have to have is Node. So you have to have Node installed, because you can run it using a command called npx. And what it does is it, it won’t download it and add it to your project, but it will just kind of reach out and run it once and then do its thing. So you need to have Node installed.

    This does work, to the best of my knowledge, it works pretty well across all the platforms. I believe there is an issue in Windows with a very specific configuration that doesn’t copy a file to the right place. But that’s less about the scaffolding tool and more about the build process. But there’s a lot of people that work on this stuff. So I’m sure it’s going to be remedied pretty soon, yeah. The only dependency is Node, which is cross platform.

    [00:26:02] Nathan Wrigley: Right, okay, perfect. So if I’ve never done this before and I want to get my first block done. Realistically, how long is it between me thinking, hmm, create block tool, I’m going to start using that, to having my first block on the page? Are we talking 10 minutes, an hour, less?

    [00:26:20] Ryan Welcher: Two minutes. Assuming you have Node installed. Let’s assume that. You can go to the documentation page and you can run npx at WordPress slash create block and give it a name, and it will prompt you for a bunch of questions. Like, what do you want to call this thing? What name space should it be in? You know, what’s the description?

    It’ll ask you a bunch of questions and it’ll just scaffold out the block for you. And the most amount of time is waiting for the dependencies. So that the block needs to be installed and then run. And that, honestly, I did a YouTube video on my channel where I timed it. And I think it took four minutes from start to finish and it was done.

    And you have a fully functional plugin with a single block in it. And you enable it, and like I said, the block is available for use immediately. No, the block doesn’t do anything. It’s a very, very simple block. But that’s how quickly you can get up and running with it.

    [00:27:09] Nathan Wrigley: Yeah, I think it’s probably very important at this point to describe the limitations, because when I heard about Create Block Tool, I thought to myself, oh great, a tool which is going to help me to create blocks. Not literally create a block, but, you know, add in options and different, custom data and all of that. And that was what I was thinking I was going to get. So just draw a line, make it really clear what you get when this process is complete.

    [00:27:34] Ryan Welcher: You get what’s referred to as a static block. So there’s two types of blocks, static and dynamic. And I can get into that if you want, and with no controls. So basically the block will, it shows you a message when you insert, it says hello from the post editor. And then it’ll render that same message on the front end, and there’s some CSS that’s supplied to the front end and the back end.

    So it’s a very, very, very basic block. The tool doesn’t have the ability to say, I want to be able to insert post meta. We can’t do any of that level of customization, because there’s just too many options. Like there’s too many ways that you can build a block, and too many things a block can do. So there’s just no, there’s no way for us to build a tool that says, I want to build a block that accesses the REST API to retrieve this custom post type and display all of the information and do all the stuff.

    That’s not something that the tool can do. But, what you get is a fully functioning, working block that is scaffolded to best practices, follows best practices. That shows you how to deal with the CSS, and how to enqueue all your different files, and everything is just built and ready to go for you.

    And then at that point you have a starting point. So, as a developer, I used to hate having to do the busy work. What this does is this basically gets me a starting point, and now I can add the things that the client is paying me to do, right? I can add the controls. I can add the interface items, whatever you’re building in your block. Iit gives you the starting point to actually build the thing that you want to build, not the, you don’t have to do any ramp up to get there.

    [00:29:01] Nathan Wrigley: Yeah, so within two or three minutes you’ll have a block. All of the files in the right place. Everything’s set up. Good to go. And then, really, dear developer, it’s over to you. You got to figure out where to go from there. Do you have any, is there any sort of commenting in the files that’s been added additionally to give you some sort of pointers as to, okay, this is what this is doing, this file is used for this and so on?

    [00:29:24] Ryan Welcher: There is. It’s commented fairly decently. There’s kind of a fine line because if you want to use these for production, you know you’re going to be removing a lot of those comments. There’s a couple of files that every time I use it, I hate how well commented it is because I like to structure my files in a specific way. So there’s a lot in there.

    And then, at this point too, the sort of, the structure, the file structure’s very well documented and it’s just been adopted. People can change things and people can, it’s very flexible. You can do it whatever you want, but the best practice has been well defined at this point.

    It’s like that muscle memory thing. People just know that, oh yeah, okay. So I want to go to the edit.js file, because that’s what I, that’s what I changed to get it to make changes in the block editor experience and so on and so forth.

    [00:30:05] Nathan Wrigley: Do you know if, well, WordPress’s mission, I suppose, is to democratize publishing. And it would be, I suppose, an endeavor worth undertaking to have a tool which did carry you on from where the Create Block Tool got you to. In other words, a tool which helped you along the process of creating the block.

    Do you know if there are any endeavors, any quiet whisperings in the dark corners of Automattic about this kind of tool? Is there any plan to do anything like that so that blocks can be created by, well, non-technical people?

    [00:30:38] Ryan Welcher: There are tools out there in the community. Like I would hesitate to say that Automattic has any sort of secret plans, because that’s not really how it works. It’s more, it’s driven by the community. I mean, I know Automattic does employ a lot of developers who do contribute to the project.

    But a lot of these tools come from the community and, for people like me to talk to folks and be like, hey, that’d be a really cool feature to add, to Create Block. There’s been a number of features where we’ve been like, you know what? It’s a really great idea, it’s too specific. So it might be better served as a tool.

    But I will say this, the create block package does have the ability to, you can provide what are called templates. So you can create your own custom template. So you can build a block that does X because you’ve built a template. So I could build a template that is like, all right, I want to block that interfaces with custom post meta. And so I could build that template and when I run the package, I can point the package at that specific template and it will scaffold the files out, and I will have all of those starting points in there.

    It’s not an interactive tool. I don’t think where you’ll see, what do you want this block to do? Like, unless somebody comes up with this really cool OpenAI integration, which might be a lot actually.

    [00:31:43] Nathan Wrigley: Somebody will probably do it.

    [00:31:45] Ryan Welcher: I’m sure they will. Blocks can do so many things and they’re so versatile and they’re so, it’s sort of like, how do you even start to define the questions that you ask in the automation process to say, what do you want to do? Like, do you need to access data stores? Sure. Is it a custom data store or is it one of the ones that Gutenberg provides? You know, so there’s a lot, there’s a lot that goes in there.

    [00:32:06] Nathan Wrigley: Does the tool itself get regular updates? I’m imagining that the technology behind that is fairly fast moving, and there’s a lot of new updates.

    [00:32:15] Ryan Welcher: It is being updated regularly. The package itself gets updated every two weeks when the Gutenberg project, so when the Guttenberg plugin is in release candidate. But there are features being added all the time.

    For example, we added the feature not too long ago to be able to copy php files around. And, there’s a lot of sort of under the hood things that, I’m drawing a complete blank of all the features that I’ve added to this thing, but we’ve added a whole bunch. Here’s an example. So when you scaffold out the block, all of your JavaScript files sit inside a SRC or a source folder. And people, they may not necessarily want that because they might already have a source folder.

    They might want to call it something like, so if you have an existing project, you might want to call it blocks instead of source. So what we did was we added the ability to be able to target that differently. So you could call it something else. And this works with the scripts package too. So you could define it a certain way and then have scripts look at that. Or one big feature that people were asking for was, we don’t want to scaffold a plugin every single time.

    If we have an existing plugin, we just want the block. So we built a no plugin mode where you could run it inside your source directory and it would just give you the block files. And now you’ve got a second block inside that plugin. So those sort of things. And those all came from the community. They all came from people using the package and saying, this is stumbling block for us because we have to copy and paste and move things around.

    Why can’t we just add a command that does it? So we were able to add that stuff in and it’s, I mean, I think it drives adoption, but it also. The whole point of this is to make people’s lives easier. If it’s more work to use the tool than it is to do it manually, then it’s, I don’t think it’s worth, you know, the juice isn’t worth the squeeze, so to speak.

    [00:33:47] Nathan Wrigley: Yeah, that’s a good point. It just occurs to me that we never said where we find this tool. Do you happen to have a handy URL available?

    [00:33:54] Ryan Welcher: Yeah, you can look in the developer.wordpress.org. I’m not going to read the whole url, but just do a search for create block. All the documentation is available there. It’s actually hosted on npm. So, I’m sure we’ll add it to the show notes, but the documentation is all there and it explains how to use it and all the available flags and all the available commands that you can do.

    There’s even a more advanced page on creating custom templates. I really love the custom template idea. Well, what do they call it? They call it external templates. External project templates is the official name. And what it allows you to do is like, if you’re an agency and you want to build blocks in a very specific way, you can define that and then everyone in your agency is going to use that same template with this package.

    And you can use local packages, or you can host them on npm if you want to share them. It’s very, very, very, very versatile. With that, the sky’s the limit. You can literally do whatever you want.

    You can scaffold the block to do anything, and then just target that particular sort of style of block. Like I built one that would do dynamic blocks because at the time the tool didn’t support dynamic blocks, and now it does, by the way. My template is obsolete now, but that was a thing that we needed. So if you wanted to build a dynamic block, you would just target my template instead of the built-in one, and you would get that sort of flavor of block.

    [00:35:06] Nathan Wrigley: You, mentioned a little while ago, maybe 20 minutes or so ago, that there was this dynamic block, and you said you might digress into that, but we never did. So let’s go down that little path just for a moment, yeah.

    [00:35:16] Ryan Welcher: Sure thing. So like I said before, there’s two types of blocks. We have a static block and we have dynamic blocks. So a static block, the difference is basically where stuff is saved or if it’s saved. So, in a static block. So all, I’d say the majority of core blocks are static, meaning that when you hit save, it actually saves the markup into the post content.

    So it’s saved to the database. A dynamic block doesn’t do that. A dynamic block uses php to render the front end, the way we would always sort of, add run until the pages loaded and that file is run, and then it displays its information. And that’s basically the difference.

    Now there’s some trade offs for both. With static blocks, when there’s markup changes, you have to do this thing called deprecation. So you tell Gutenberg, if there’s any developers listening, I’m sure there are. If you’ve ever seen that, like, you know, the block, we couldn’t render the block. There was an error. Everyone’s seen that error. That’s because some markup has changed.

    You need to deprecate that. So that’s an extra step. Where with dynamic blocks, you don’t need to do that because it’s always run live, so to speak, right? So there’s some benefits to using a dynamic block for that regard. But the trade out there is you have markup in two places. So that’s, at a high level, the difference.

    [00:36:26] Nathan Wrigley: And the create block tool will point you in the right direction of creating one or the other, depending on which your.

    [00:36:33] Ryan Welcher: Yeah, it lets you choose. So there is a flag called a variant, and you can choose between static or dynamic. I believe the default is static. It’ll give you a static block if you don’t run that flag. But if you say variant dynamic, it’ll do a dynamic one. And then there’s actually, within your templates, this is getting really the weeds, but if you define a template, you can actually have multiple variants. So you could have your own variant. You could have a TypeScript variant for your particular template. Or like a, I don’t know, Tailwind CSS one. So there’s a lot of flexibility there is where I’m going with that.

    [00:37:03] Nathan Wrigley: Amazing. So much going on in the WordPress space at the moment. On every level. From straightforward to incredibly complicated. And feel this is on the incredibly complicated side, but really interesting work. You mentioned that you are obviously into this, but there were a couple of other names which came off your tongue earlier. I’m wondering if in the round, you could just drop some of those names, people that we might like to go and find, as well as yourself, who are working with you, pushing the Create Block Tool.

    [00:37:36] Ryan Welcher: There’s the folks that I work with on my team. I’m sure you’ll know all these names. Birgit Pauli Haack is on the team. She’s the Brains behind Gutenberg Times and all that stuff. Justin Tadlock is on the team as well. I’m sure everyone knows Justin. There is Michael Burge who is on our team, and think that’s it.

    [00:37:54] Nathan Wrigley: Yeah. Well if there’s any that you’ve missed out, you can always fire them over in my direction and we’ll make sure, that they get into the show notes. If anybody has been listening to this episode and they’ve thought, you know what, this is curious. This is something that I need to begin to play with, but I would like to find out a little bit more first. We know you’ve got the Twitch channel, and we’ll push people towards that. But what other places can people get in touch with you Ryan?

    [00:38:19] Ryan Welcher: Sure. I have a YouTube channel as well, so I’m Ryan Welcher Codes in both places, Twitch and YouTube. I try to answer the comments on YouTube as often as possible, but sometimes I don’t get to them right away, but I’m at Ryan Welcher on Twitter and my DMs are open, so feel free.

    I’m Welcher or Ryan Welcher or Welcher Ryan in a million different Slack channels. So, I think I’m Welcher in Make Slack. I’m on Post Status. I’m on Discord in a few places. So just search my name or variations of my name and I’m sure you’ll run into me and, I’d be happy to speak with anyone one-on-one in a public forum, whatever, whatever works.

    [00:38:54] Nathan Wrigley: Thank you for making yourself available, and thank you for talking to us today about the Create Block Package stroke Tool. That’s been really, really interesting. Ryan, thanks so much.

    [00:39:04] Ryan Welcher: Thanks so much for having me and I hope I can come back sometime.

    On the podcast today we have Ryan Welcher.

    Ryan is a developer advocate sponsored by Automattic. He has been developing with WordPress since 2009 and before becoming a developer advocate, worked for agencies large and small and as a freelancer.

    If you’ve been using WordPress for any length of time, you’ll have come across the new paradigm for content creation, blocks. Every part of your website can now be created and amended as a block. Pages, posts, text, images, headers, footers, navigation and more.

    This has widened what’s possible for people who don’t want to mess around with the code of their website. You can add in blocks for almost anything, and change how it looks and behaves from within the block editor interface.

    This is an excellent move forward, but there’s still an impediment for non-technical people, because creating a block of your own is difficult. If you are able to use the selection of blocks that ship with WordPress Core, or you can find a third party block which does what you need, great, but if you need something specific, you’re going to have to create your own block solution, and that can be hard.

    Ryan is on the podcast today to tell you about the create-block tool, and how it can make your pathway towards block creation a little easier.

    We start off talking about Ryan’s background, and how he became interested in WordPress. We then move on to how he thinks that the adoption of blocks is becoming more widespread given the maturing of the tools and learning materials available.

    The conversation then turns to how the create-block tool can help you scaffold your blocks. It’s not a tool which is going to build the blocks for you, but it will help you set up the environment and build process, which you need to get started. Really, it’s all about saving you time and effort on things which don’t really get you building your blocks, but which you need to do that work.

    We discuss what you can expect from the create-block tool, and the prior knowledge that you’ll need to have once the tool has you up and running. What level of expertise do you need, and is the tool under continual development?

    We spend a few moments talking about the livestreaming which Ryan does each week in which he live codes solutions to viewers block based problems.

    If you’ve thought about creating your own blocks, but have been put off by the technical barrier, this podcast is for you.

    Useful links.

    10up

    Gutenberg Examples GitHub repository

    WordCamp Asia

    create-block package

    learn.wordpress.org

    create-block documentation on npm

    Gutenberg Times

    Ryan’s YouTube and Twitch channels

    Ryan’s Twitter

  • #72 – Steve Bruner and Timothy Jacobs on Using Gutenberg Outside of WordPress

    Transcript

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case using Gutenberg to build the Awesome Engine SaaS app.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcasts players.

    If you have a topic that you’d like us to feature on the podcast, I’m very keen to hear from you, and hopefully get you all your idea featured on the show had to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today we have Steve Bruner and Timothy Jacobs.

    Steve has been active in the WordPress community for the past 17 years. He’s a WordPress developer, co organizer of the WordPress NYC meetup, and has organized many word camps in New York City.

    Timothy is a WordPress core committer for the REST API, and has been a WordPress developer for over 10 years. At StellarWP he leads development of the iThemes security plugin.

    What brings them together is that they’re both founders of a SaaS app called Engine Awesome, where Steve is the CEO, and Timothy is the CTO.

    What has this got to do with WordPress, you might ask? Well, they’re here today to talk about Gutenberg, but not how you might expect. It’s Gutenberg outside of WordPress, but Gutenberg, nonetheless. Like all of WordPress, Gutenberg is open source. You are free to download it, modify it and use it in whatever way you like.

    When Steve and Timothy began working on their new project and needed a way for their clients to interact with it, they found Gutenberg was the perfect tool for the job.

    We talk about what benefits they’ve gained by using Gutenberg. How it saved them time, and how it’s fast becoming a stable and mature product which is easy for non-technical users to understand.

    We get into the details of which parts of Gutenberg they used, and which parts were not suitable for their app. They’ve been building their own blocks, which work well in the UI, but which are more suited to the kinds of data that they’re gathering.

    The discussion then moves on to what Awesome Engine actually does. It’s an app builder in which you can construct your own data containers and theme them so that it displays in any way you like. They tell us about the features, which they have so far, as well as the items which are on their roadmap.

    Towards the end we talk about their commitment to continue contributing back to the Gutenberg project, and how they feel that it’s in everyone’s interest if the project gets better from any updates that they have made.

    If you’re looking to build your own SaaS app, or you’re just curious about how Gutenberg is being deployed outside of WordPress, this podcast is for you.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast, where you’ll find the other episodes as well.

    And so without further delay, I bring you Steve Bruner and Timothy Jacobs.

    I am joined on the podcast today by two gentlemen. I’m joined by Steve Bruner and Timothy Jacobs. Hello.

    [00:04:23] Steve Bruner: Hey Nathan. Nice to meet you.

    [00:04:24] Timothy Jacobs: Hey.

    [00:04:25] Nathan Wrigley: Steve. Firstly, did I pronounce your surname correctly?

    [00:04:29] Steve Bruner: You did absolutely.

    [00:04:30] Nathan Wrigley: First try. Yeah, that’s great. Well, thank you for joining us on the podcast today. We’re going to be talking about something which we literally haven’t covered in any way, shape, or form at all. We’ve talked endlessly about Gutenberg and the Block Editor, and blocks and patterns and all of that. But we’re kind of staying away from that, despite the fact we’re going to be talking about Gutenberg. Because we’re going to be talking about an app which has been built on top of Gutenberg, but really not that connected to WordPress. So buckle up. This will be an interesting episode.

    We like to orientate the listeners as to who you are so that when they’re listening, they know that you are an authority on what you’re talking about. So can I take you in turn? Can I go Steve, first? Would you mind giving us your little potted history of who you are, what you do for a living, where you live, and what your relationship has been with WordPress?

    [00:05:18] Steve Bruner: Sure. So back in my previous life I was in like marketing and sales. I embraced technology back then and using spreadsheets and eventually Microsoft Access, I was able to do more than anyone else on my team, right? I could do 10, 20 times the amount of work, just writing macros in Excel or, do database config in Microsoft Access.

    And I loved playing with technology and started playing with HTML, and a friend of mine about 17 years ago, 18 years ago, introduced me to WordPress, said, this is pretty cool, you may want to check it out. And I really loved it. It was easy and it was hackable and it was a lot of fun.

    Eventually somebody asked me to build them a website. Somebody else offered to pay me to build them a website. And that just grew over the years until I became a full-time, I guess, solopreneur. I have an agency, but I do hire out contractors on a regular basis. I have relationships with many contractors who I’ve been using now for over a decade.

    I also ended up back then taking over the WordPress meetup in New York City. It was about 400 members, now it’s 9,000. That really gave me a good introduction to WordPress. It introduced me to a lot of people, and I learned. In the very beginning of a meetup, for those of you who are trying to start one, if you don’t have somebody who will present, you are the presenter.

    So for the first year, year and a half, I presented every month, third Tuesday of the month. Did that for a year and a half until we started getting more presenters in. So that grew and yeah, I’m a full-time WordPress developer now.

    [00:06:56] Nathan Wrigley: Isn’t it curious how, if you have been using the internet, let’s say, and building websites for anything like 20, 30 plus years, you kind of more or less fell into this job. I’ve yet to come across anybody of my age, shall we say, who’s been doing this for that length of time who sort of decided from the outset, that’s what I’m going to do.

    The story is always the same. I was doing something else and then I discovered HTML and played with CSS and realized, oh, I could actually make a living with this. What fun.

    [00:07:23] Steve Bruner: That’s exactly right. The fact that WordPress is open source. You can run it locally. I learned how to code, and this is not an uncommon story, right? I learned how to code by changing code in WordPress. By commenting things out and changing things, and just seeing how it worked.

    [00:07:39] Nathan Wrigley: Yeah. A verified tinkerer. It sounds like a man after my own heart. Okay, so let’s move on to Timothy. Timothy, same question really. Give us your background story and particularly your relationship with WordPress.

    [00:07:52] Timothy Jacobs: For sure. I’m also based in the New York City area, so you can guess how I met Steve at the WordPress New York City Meetup Group, which I also help co-organize. But aside from that I’ve been working with WordPress now for about ish 10 years or so. My day job is I work over at StellarWP on iThemes security. So I’m the lead developer over there.

    But I also have yeah been involved with the WordPress community for a bit. I’m right now a WordPress core committer. I help work with the REST API in WordPress Core. And then also try and, you know, work with the Gutenberg team as well on REST API things and bringing the two together and helping everything work.

    [00:08:29] Nathan Wrigley: Well thank you. At the outset of this podcast it might be useful if you are listening to this and you’re anywhere near a computer. Just pause for a moment and go to the URL engineawesome.com. It is exactly as you’d imagine. There’s no funky spelling there, engineawesome.com.

    Go and have a poke around because I feel that the context that you’ll get from doing that will put you in a good position to enjoy this podcast episode more. So come back and we’ll get on with the ride. So first of all, whoever wants to answer the question, what is Engine Awesome? We should probably clear that up straight away.

    [00:09:03] Steve Bruner: Great. So yeah, I can answer that. Engine Awesome is a SaaS application, and for those interested it is built using Gutenberg, but Gutenberg using Laravel, not WordPress. But it’s a SaaS application that allows you to build applications for your business with absolutely no code, just using blocks. You could build your own CRM. You can build an order management system, a donation system, project tracking, to-dos. Anything you want in the config that you need.

    [00:09:33] Nathan Wrigley: So the ability to do that in SaaS software, there’s probably a multitude of apps that we could go to that offer, I guess, something fairly similar. You know a no code tool which allows you to build something custom. But the unique bit which has got you on this podcast today is the fact that you’ve chosen to do that outside of WordPress, but still using Gutenberg.

    And I want to know why. I want to know why was it that you decided to take that on board? I can imagine there’s a whole bunch of reasons, but they would be guesses. So let’s delve right into

    [00:10:09] Timothy Jacobs: Yeah, so I think one of the big things is that the user experience that the block editor provides, while there’s always places that it can be improved, is really excellent. There are so many tools out there where the first years of their development are, how do we build a good UI for dragging things onto the screen and making it look like you would expect it to look.

    And how do we, you know, have settings that adjust things and make tweaks and have visual changes? And how do I navigate to different areas, and how do I present blocks of content? I think WordPress, the block editor in Gutenberg, isn’t really the only block based system that’s out there. Lots of different tools have come to realize the power of the block.

    But the block editor in Gutenberg being open source, lets us have tons of customization ability. So it really gave us a great headstart for building out an application user interface, where we could get right down to the meat of it, instead of worrying about all of the bits that go into building a WYSIWYG block editor interface.

    [00:11:13] Nathan Wrigley: It’s almost like the use case for using WordPress to build a website in a way, isn’t it? Because it does a bunch of the heavy lifting for you. You don’t have to invent all the user permissions yourself, and write all of that code. You can get yourself off to a flying start by implementing something which is freely available and ready to roll.

    [00:11:31] Timothy Jacobs: Exactly. It gives you that same kind of headstart. And it also provides like a great prototype experience. The first prototype that we built out was just by building some custom blocks in a WordPress, Gutenberg system. Not even with a whole Laravel side of things. It’s just a great place to prototype.

    [00:11:48] Nathan Wrigley: So Steve, I don’t know if you have anything to add to that, but basically why Gutenberg? If you’ve got a different answer than Timothy’s, go for it.

    [00:11:56] Steve Bruner: Tim’s the CTO, so his is a little more technical. Mine would be a little more business oriented, I guess. First off, the Gutenberg UI is proven, right. It’s a proven UI that works well, and millions of people and millions of websites use it every day to build websites. So not having to deal with that, not having to work on a UI and go through the whole trial and error process really was appealing to us.

    Gutenberg gave us, we probably would’ve taken two years, three years to build this out if it wasn’t for Gutenberg. So having that head start, having a UI that’s proven, that works. And if you’re coming from the WordPress world, you’ll feel natural. You’ll feel comfortable in Engine Awesome, because it’s Gutenberg, right? We have some custom blocks and some custom workflows, but at the heart of it is Gutenberg, and you will, you’ll feel very comfortable using it.

    [00:12:48] Nathan Wrigley: So given that Gutenberg itself has been how to describe it? It’s been tumultuous over the last few years. You know, there’s been a lot of changes, a lot of rapid iterations. I guess that’s slowed down a little bit more recently when the whole project seemed to move over to full site editing and all of that. Is that a concern of yours? Have you frozen your version of Gutenberg in time? Or are you keeping up with the very latest and greatest that that project offers?

    [00:13:13] Timothy Jacobs: We are keeping very up to date. I think we are one version of Gutenberg behind usually. And that’s where we like to keep it at. But yeah, just a couple of weeks ago, we added support for fixed positioning. Which was a feature that the main Gutenberg team had just introduced. So we see that the, like, iteration speed of Gutenberg is a benefit.

    A big thing is that as Gutenberg is maturing, and now we’re seeing Gutenberg with the isolated block editor project and coming to the wordpress.org forums. And of course what Automattic is doing with Tumblr, that the core WordPress Gutenberg packages, while they are moving very fast and you do have to keep up with them, they are kind of stable enough that you can build on top of them in this way.

    And they have to be so that those projects don’t just keep breaking. And so WordPress.org doesn’t just keep breaking. While it is not as stable, let’s say as WordPress Core pre 5.0, and just building on top of the WordPress Core PHP. I think it’s stable enough to build on top of, for sure.

    [00:14:19] Nathan Wrigley: Did the nature of what you were trying to achieve, and we can dig into exactly what it is that you are solving in a little while, but did the paradigm of blocks fit pretty neatly? In other words can you. atomize your workflow inside of Awesome Engine into a collection of blocks basically? Drag in blocks, reposition blocks, fill in data into blocks, and that’s essentially what the app is doing.

    [00:14:43] Timothy Jacobs: Yeah, I think so. At its core in Engine Awesome, each field, each bit of data that you’re putting into your, let’s say CRM or invoice management system, each one of those fields is a block that you create. So starting from that level of, hey, we have a block, which is a field that data can be entered into. And it doesn’t just look like, let’s say a plain text field, it looks something a bit more of a rich application user interfaced.

    The field and the block being like that common low level bit that we build on top of. Yeah, it does make, I think the block-based paradigm a good fit. There are some struggles with a block-based paradigm, and achieving some more complex layouts where things aren’t just neatly stacked in rows and stacked in columns, like a grid.

    But that is something that’s getting more and more possible to with Gutenberg every few releases. But I do think that the block-based nature, being able to map over to every block as a field did make it a good match, of philosophically in that sense.

    [00:15:45] Nathan Wrigley: Yeah, right from the outset. Matt Mullenweg ages ago, I don’t exactly know when, he had this, what felt like a really almost crystal ball gazing idea that Gutenberg as the editor would become almost synonymous with entering data across the whole internet. It would become something which was used everywhere.

    Gutenberg itself would become bigger than WordPress and all of that kind of thing. Do you see this? Do you see people doing what you are doing out there? In other words, does the Gutenberg interface, is it increasingly cropping up in places just like Engine Awesome?

    [00:16:20] Timothy Jacobs: I’m not sure if I’ve seen many cases. There are some that are out there. There is a Laraberg, as I believe the combination of names and how they landed on that one of combining Laravel plus Gutenberg, more for like a page editor context. The same way that is used in WordPress Core.

    As well as I believe there’s a Drupal integration. And I think a couple of other things. Of course, there’s the isolated block editor project and what Tumblr is doing. I haven’t seen a lot of people though that are doing it to the degree that we are doing it, in terms of, hey, we’re letting you build an application as opposed to letting you design a webpage.

    And so I don’t think we are there yet. But I think the stabilization over the past year has made it more of a possibility for projects who are looking to adopt Gutenberg in that way absolutely can, and I think it’s something worth looking into.

    [00:17:10] Nathan Wrigley: How much of the core Gutenberg blocks do you bring along? And how much of it is bespoke work for your application? I’m presuming, I mean, you alluded to it earlier. I think you said you’ve got some of your own custom blocks in there. Do you bring almost everything along for the ride, including, I don’t know, the Vimeo embed block or whatever it may be? Or do you pull out a certain amount and keep a certain amount only?

    [00:17:32] Timothy Jacobs: Yes, this is actually, it’s a really interesting question in terms of how functionality in Gutenberg these days gets divided. So we don’t bring in any core WordPress Gutenberg blocks. But what we are able to do is, as we’ve had the introduction of global styles in the full site editor experience. There’s been more of a separation of, what are things that are really blocks and what are things that are settings that your blocks can opt in to.

    So for instance in Engine Awesome, you can use the margin tools, and the padding tools, and the sizing tools, and the colors, and the text sizes. All of these different systems. And the way that we support that in Engine Awesome is we just say in our block.json, hey, we want this feature. Gutenberg, render me the UI for it. Build me the styles. Save all of it to the block metadata information.

    Gutenberg, you handle all of that. And what I’ll do is I’ll render the part that you see in the canvas, the actual block UI. But core Gutenberg is able to handle those types of controls. So that’s where we’ve really made the delineation, is that we don’t use the core blocks, but we use all of the features that the core blocks use. And are able to pull them in without having to copy thousands of lines of code. So we for instance, have a text block and a group block, and they’re a few dozen lines of code that are really just implementing the WordPress core APIs around layout and around rich text.

    [00:19:09] Nathan Wrigley: Yeah, it’s interesting because I’m looking at your homepage now and there’s a video on there showing what is obviously to me, the Gutenberg interface. I guess to your customers maybe they’ll recognize it as that, maybe not. But it shows the inserter, the panel on the left opening up, and it really does look the same.

    And so I made the mistake of thinking they were core blocks because many of them map really similarly. You know, you’ve got a text field and then you’ve got a URL and the iconography looks remarkably similarly. You haven’t really tweaked that in any way. It really, really looks like the interface right down to the colors and everything is exactly the same. Black text, black icons, blue buttons, looks similar. That’s a curious choice that you decided not to fiddle with the design of it.

    [00:19:54] Timothy Jacobs: Yeah, I think the design of the block editor, like Steve was mentioning, is really well proven. And I think there are places where maybe in the future that we do more customization, based off of how our users are going to be using Engine Awesome. And the differences between the block editor in WordPress Core for designing pages and the block editor in Engine Awesome for designing applications.

    But I don’t think we wanted to take an approach of, well, let’s just redesign it for the sake of redesigning it without knowing hey, here are these specific UX benefits that we want to change and we want to improve.

    The other aspect of it, to be honest, is that some of these components are harder to tweak than others. Like the inserter, for instance, is a very complex component. So we don’t want to just say like, okay, let’s rip it all apart. That’s one of the aspects where I think you can get into a little bit of trickiness with the rapid pace of Gutenberg development. Is that if you rip everything and everything and everything down to its very bare bone bits, then it is a lot harder to stay up to date with Gutenberg and to be on the latest versions. It makes each upgrade a little bit more of a chore. Whereas for us upgrading Gutenberg isn’t very difficult.

    [00:21:15] Nathan Wrigley: So I guess if you’re a listener to this podcast, the chances are that you’ve played with Gutenberg in the past and you’ve experienced how it works and this whole process in Engine Awesome will be really familiar to you. But it also raises the question, you know, in WordPress there’s a whole ton of different blocks out there now. If you, you know, you can go to the internet and download thousands, possibly tens of thousands of different blocks. And, so you are using that block methodology in your application.

    It feels like we’ve sidestep the, the most important question, which is what on earth, what an earth does this SaaS platform actually do? So it might be a good idea to bring Steve back in at this point and ask what is Engine Awesome? What is it doing?

    [00:21:56] Steve Bruner: Yeah. So like I mentioned before, I’ve been running a small business for almost 20 years. Full-time for, you know, close to 10. And I’ve tried every piece of software out there to help you run your business, right? I’ve tried every CRM. I’ve tried every project management tool and to-do list and anything you can imagine, I’ve tried.

    And to be honest with you, I haven’t loved any of ’em. And anybody I’ve spoken to has said the same thing. Usually when you try these out of the box solutions, you feel like you’re overpaying for a product where you’re only using 50, 60% of the features. And they keep loading it up with more features and they keep raising the price.

    With Engine Awesome you get to build exactly what you want. You build the CRM that you want in the way you work. The way your team works. The way your business works. We have had clients that have taken paper forms that they’ve used in their business and replicated them in Engine Awesome. And their employees just log in and they know how to use it. There’s nothing strange here anymore. They see the same form they’ve been using for years, it’s just a digital version. So training comes down and training costs come down.

    Now, there are other no-code platforms out there. We realize that there are others that are doing this. Our goal is to make it simple. To make it really, really simple for you to get your application up, right. Tim and I always talk about getting our clients up and running in minutes, not months. You don’t have to know anything about databases to use Engine Awesome. You don’t have to know about key fields and indexing fields. You don’t have to know how to build relationships. You don’t have to do any of that stuff. Engine Awesome takes care of it for you very easily. Just drag and drop some blocks, check a box, press save, and you’re ready to go.

    [00:23:55] Nathan Wrigley: I’m seeing when I’m on your homepage, I’m seeing what looked like the two UIs. I’m seeing the Gutenberg UI, which obviously has a purpose, but I’m also seeing like another UI where I don’t know what’s going on there. Is it, do you have a UI to build the blocks themselves and then they’re created inside of Gutenberg to drop in whatever data it is that you need to put into that particular block?

    [00:24:18] Timothy Jacobs: Yeah, so we have two different base points. They’re both Gutenberg. But the first step of building your Engine Awesome application is deciding what fields that you want to support. So what data you want to collect. And this is just dragging from the inserter, a URL, or a name, or a color, and bringing them into a separate editor where you see all the list of fields that you’ve created for this particular, what we call an object type. For WordPress users it would kind of be most analogous to a custom post type.

    And so your contact, for instance, might have a name field, a phone, an address, things like that. Those fields that you define when you’re editing your object type, make up the inserter, make up the block library when you then edit your layouts. So you first define your kind of data that you’re looking to collect. And then you can define as many different user interfaces that you want to show that data or collect that data. And Steve can give some good examples of how that interface building portion happens.

    [00:25:19] Steve Bruner: Yeah, so a lot of our clients come from using spreadsheets, for instance. Just giant spreadsheets. 30 columns, thousands of rows. And it’s really easy for them to work with Engine Awesome, right. So as Tim mentioned, first they define their object and then they literally are transferring those fields from a spreadsheet to Engine Awesome using the blocks.

    Then they go and start creating their layouts. And the layouts are, they could be forms, right? Where you’re entering data. They could be tables where you are viewing data. They can be queries where you’re searching for data. And those layouts also are conditional.

    They can change based upon data that’s entered. So, for instance, if you have quote that you provided through an Engine Awesome system, and that quote is in maybe an open status, you will see certain fields that are there. But once that quote gets changed to an approved status, those fields will be locked, right?

    You’re not changing the quote after it’s been approved. So fields are locked. Nobody on your team can enter data or edit data anymore. And then you can move through a process. And again, I just want to reiterate, that is not a set process in Engine Awesome, that’s a process that somebody would’ve built, right? Everything is custom.

    So those layouts, change in Engine Awesome. One other UI I guess that we have. We recently brought in the full site editing experience, or I guess the full, Tim can talk more about this, but the full site editing UI as the actual application UI. So when you are building your object and building your layouts, you see the inserter, the settings, Gutenberg like everyone is really familiar with it. But when you’re using the application, when your team is using the application, when they’re in the field or in the office, we are using the full site editing experience with the full site editing menu. And Tim, maybe you want to elaborate on that?

    [00:27:20] Nathan Wrigley: Yeah, please.

    [00:27:21] Timothy Jacobs: Yeah, so you can kind of see this, if you go into our post, Engine Awesome has a new look. And you can kind of see that delineation there. Basically the Gutenberg team introduced a really fantastic collection of navigation elements. And so we were able to use those to say, here’s how you navigate between different views, between different object types, between different sets of data. And use that navigation experience that the core Gutenberg team provided.

    [00:27:48] Nathan Wrigley: Yeah, I will link to that post. But anybody listening, there’s a blog post. Currently it’s linked in the footer, but I imagine over time it will disappear from the footer of the main homepage. It’s called Engine Awesome has a new look and you can see the site editor panel on the left and all of that. Yeah, that’s a really interesting implementation.

    So you build out the structure of the data you want to consume, you then have the option to display that. Presumably there must be a whole piece of making that data interact with other data points.

    So, you know, you just mentioned that something is marked as approved. So certain fields get locked up. But presumably there are relationships, child, parent relationships, one-to-one, and so on and so forth, that bind the data together. Otherwise, you’re looking at a spreadsheet, aren’t you, really? So there must be something more in here.

    [00:28:35] Timothy Jacobs: Exactly. So when you edit your object type, you can set up a relationship between another bit of data, and then when you do that by dragging a block. So you’ll see in your inserter, for instance, let’s say that you are editing a contacts object type, and you already have a company’s object type set up.

    The only thing that you need to do is drag a block that says that this contact has one company and then Engine Awesome takes care of the rest. And so then when you’re building out a layout, let’s say for a company, you can easily display a list of all of the contacts that are associated with that company or vice versa.

    When you’re editing a contact, you can say, hey, here’s a snapshot of information about this company. Maybe their address, their website, a photo of them. Just to give that contextual information. So you can set up all of those object types and all of those relationships just by dragging a block into the block editor.

    [00:29:29] Nathan Wrigley: Steve, it sounded like you wanted to chip in there.

    [00:29:31] Steve Bruner: I was just going to give you a couple of use cases so you can get a good understanding of how people are using Engine Awesome. So recently a non-profit provided us a spreadsheet, a thousand rows, 26 or 30 columns, and they were tracking their donors in it. And it really is not the best way to do that. In five minutes, and I really mean this, I’m not joking.

    Five minutes, maybe six, on a Zoom call with this prospective customer, I built an application for him where he was able to enter donors and then keep a record, a log of donations. See those donations, filter those donations, and get a good understanding of what’s going on. So it was really really quick and is going to change the way he does his job and his team’s job, and everyone’s just going to be, everyone’s life is going to be easier.

    We have a home cleaning service, a residential home cleaning service. Tim has done a great video, you’ll find it on our YouTube channel about how to build a service business application, and in 30 minutes, and this is a live video that Tim did, and you’ll go through it. Tim is not going quickly at all.

    But in 30 minutes he built an application that tracks this home cleaning services clients. The jobs they do. Their team members and their teams. They go into people’s homes, they bring up Engine Awesome on their phone. They view their jobs. They mark their job cleaning when they’re starting to clean, and then they go through this whole process.

    And when they’re done, they mark it done. Eventually they’re going to be taking credit cards using Engine Awesome. So, we have a Zapier integration where when the job is done, the client will get an email automatically with a payment link. And this is changing her business, right? Right now, she deals with cash or check or Zelle. Sometimes people forget. And it’s just making her life much easier.

    Even something crazy like a marketing company that has displays in Home Depot stores. They are going to be doing a test in a couple of hundred Home Depot stores. And they built a UI in Engine Awesome that tracks stores and products and promotions and using our web hooks and API, they’re going to be pushing data to those stores, to those displays, and managing it all in Engine Awesome.

    So ideas that we never even thought of, people are starting to use Engine Awesome for some really, really creative ideas. You know, at the core of it, Tim and I really are passionate about helping businesses be more productive every day. And I think these use cases give a good, broad example of that.

    [00:32:06] Nathan Wrigley: I don’t know if either of you have ever used a piece of software called Airtable? But Airtable came around, I don’t know, maybe five or six years ago and it felt like a really, quite an interesting piece of technology at the time, in that you could put data in, it was basically a spreadsheet, but then it could show you that data, back at you in a variety of different ways.

    So that leads me to the question, is that possible here? It sounds like the answer’s yes. So, as an example, let’s say that I’m a real estate agent and I’m updating data about houses on my roster. And I’ve input all the fields. I’ve got images. I’ve got prices and descriptions and maps of floor plans, all of that kind of thing.

    Is it possible for me to create bespoke layouts of that data? So rather than it just being an Airtable, which looks like, well, a spreadsheet, you’ve got other options in there, but basically a spreadsheet. Is it possible for me to, I don’t know, float images right? Or highlight this particular aspect of the text? Make this a heading and you know, add iconography.

    In other words can I make the data engaging to look at? And further to that, can I bind those presentation layers to members of my team? So for example, could the sales director see a different layout of different data and somebody who’s in marketing, front of shop, might be able to show data to a customer that walks in the store? That kind of thing.

    [00:33:23] Steve Bruner: Yeah, so it’s interesting you brought up Airtable, right? Because Airtable is a no-code solution that, like you said, is mostly a spreadsheet. And I want to get back to that because I think Tim and I, we feel a little differently than the way Airtable and some other no-code solutions do their business.

    But to answer your question, yes. You can build really compelling, beautiful layouts using Engine Awesome. Because you’re using the Gutenberg design tools, right ? So you’re essentially designing a webpage, but it’s a, you know, maybe it’s a form or tables or some type of layout. But yes, you can float things, right? You can float through things left. You can bold, change colors. We have themes. We brought in themes as well. So with one click you can change the color and style of your application.

    In terms of different team members using Engine Awesome and seeing different things and seeing different items. This is a really important point, right. Tim and I are actually going through this right now. How we want the user roles and capability system to work i Engine Awesome. Because our goal, and this is the goal we’ve had since day one. I think this is also what makes us different from a lot of no-code solutions out there, is that we want your entire team using Engine Awesome.

    We don’t charge per user, and I think that’s a really important point, right? We really are charging per organization or per team. We want everybody, we want your part-timers to use Engine Awesome. You want the CEO to use Engine Awesome. Everybody in between. You shouldn’t have to pick and choose who needs to use an application. We really believe at our core that when your entire team is on the same page and uses the same application, and can see the same data, your life’s going to be better. Your business will be better. Everybody will be more productive.

    So we’re working really hard to make sure we have this roles and capabilities system that allows to do exactly what you’re talking about, and really fine tune it. So that everyone is on the same page.

    [00:35:28] Nathan Wrigley: Timothy, anything to add to that?

    [00:35:30] Timothy Jacobs: Yeah, I would mention one thing, which is that right now we have things set up so that you can have different levels of permission. So you can have and invite users onto your team that can just read data, for instance, or who can just edit data, but they can’t make changes to your application. But yeah, the next big thing is figuring out what it looks like and how do you make it intuitive for users to set up an application where they consider different things like permissions and capabilities?

    There are some tools that, the kind of permission system is really just visibility. And if you’re a developer, you can sneak under the hood and they throw warnings all over the documentation that, hey, you know, even though you’re, you think you’re hiding this data, you’re not actually hiding this data. Because it still gets sent to every user’s browser or something like that.

    So thinking through ways to make it very intuitive for users to say, hey, how do we actually set up our permission model, is the thing we’re exploring.

    [00:36:28] Nathan Wrigley: Will it be possible to change the data on, for want of a better word, the front end? In other words, if you’ve input the data in one UI, but then you’re looking at the way it’s presented, the theme, if you like. Is it possible for, and again, user permissions, we’ll assume that that’s coming down the pike, but is it possible to have people change the data in the different displays? Or do you have to always return to the, if you like, WordPress post to amend that data?

    [00:36:55] Timothy Jacobs: Yeah, so you can edit the data everywhere. This is a trend that we’ve been seeing with a lot of these different tools. Is that they give you different layouts that can present your data, but at the core of it, they all have a data mode where you’re basically looking at a spreadsheet or a very, I’ll say charitably, a plainly designed form that doesn’t have a sense of hierarchy or related bits of information. And then you can present it in any way that you would want.

    For us though, the first thing that we wanted to tackle was to make sure that when you presented and created a beautiful layout, that your users could also edit the data in that layout. So right now we don’t have, for instance, a separate kind of raw spreadsheet like view into your data. That’s something that is on our roadmap. But our main actual priority is for users to be entering in data through the rich UIs that you create.

    [00:37:48] Nathan Wrigley: I feel that’s one of the, one of the great advances recently. The ability to change it wherever you are. I think that would be really good. Because it is frustrating if, well, you’re looking at the data that you want to amend and then you have to, in WordPress parlance, click edit post and then go and find that field and amend that field and then click save and then go back and make sure it looks how it ought to look. That’s just one of the best things about this whole approach, isn’t it? Is that you can do it right there on the front end.

    Just moving slightly. Obviously you’re a SaaS app. You’re consuming all sorts of data. Probably you can imagine where this question’s going. If you are consuming, I don’t know, email addresses, images, all sorts of financial information, whatever it may be. How are you storing that? Where is that data being kept? If I’m in the EU, do you have it in a certain jurisdiction? Is it encrypted? Let’s just leave it at that.

    [00:38:41] Timothy Jacobs: Yeah, that’s a great question. So right now we don’t have a separate EU instance for instance. Unintentional rhyming there. But the way that we’ve set this up is, we are using MongoDB as our database system. And each team that gets created gets their own, essentially database inside of MongoDB to themselves.

    So right now that’s all centrally part of Digital Ocean’s managed database service and their encryption at rest and so on and so forth. And there are a lot of great security practices. In the future though, what that means is that we’ll be able to support teams having data that is in a different data center, depending on what their needs are.

    And even for potentially more enterprise customers, the need to be able to self-host their own database. Engine Awesome is set up to be able to connect to different database applications. But right now all of that data is stored in Engine Awesome, in Digital Ocean.

    [00:39:37] Nathan Wrigley: Okay, thank you. You mentioned enterprise there, but also Steve earlier was talking about examples of local charities and things like that. So is this software basically open to everybody? And on the website, forgive me, it may be that I’m just not looking all that carefully, but I can’t see a price. So I don’t know if that’s a function of you haven’t worked out your pricing yet. Or if it’s a contact us, and we’ll talk through what it is that we think you’re going to need, and we’ll work out the pricing accordingly. But are you aiming at all the people all the time. Enterprise, just small mom and pop stores. How are you launching and what is the pricing model?

    [00:40:14] Steve Bruner: So right now most of our clients are small to medium size businesses. We’re not writing off enterprise, we just realize that enterprise may need other features that we don’t have yet. Like single sign-on or maybe a, you know, a dedicated SLA or something of that nature.

    So we’re not there yet. Obviously we’re happy to talk to enterprise. There is one larger company that expressed an interest in Engine Awesome, and we’ve been talking to them. But right now, all of our clients have been small to medium sized businesses.

    The pricing model we’re still playing with. Again, we don’t want to charge per user. So we’ve been playing with all sorts of ideas. The number of records you use. Or the resources you use. Our goal is to get you and your entire team on Engine Awesome, and we’re willing to do whatever it takes to get you there.

    So, right now we have a manual onboarding process. If you sign up for Engine Awesome, you’re scheduling a Zoom call with me. So we have a talk. I find out what your needs are, how you plan on using Engine Awesome, your pain points. And we talk it through.

    And at that point we start working out where Engine Awesome fits into your plan. For smaller teams, we’re in the $10 range a month, $15 range a month, $20 a month. But we’re not really going much higher than that right now.

    [00:41:42] Nathan Wrigley: Are you going to be making use? So we’re in phase three of Gutenberg, which is for want of a better word, concurrent editing. Think Google Docs. Are you going to be making use of that? I mean, I can see that being incredibly useful if it’s pulled off. But is that something that you are thinking about implementing?

    [00:42:00] Timothy Jacobs: I would love to. It’s something that I’m seeing, and I’m really, really excited to see how that evolves. I’m really curious how the core Gutenberg team is going to approach designing that. I think there’s a lot of UX patterns that are going to be challenging. And seeing them pull that off is going to be really interest.

    And then seeing how that connects to WordPress. Is it going to be like peer to peer? Is it going to go through WordPress, as the PHP backend? What is all that going to look like from a technical perspective I think will also be fascinating. For us, I think one of the benefits of being a SaaS application is that it makes it a little bit easier for us to do that kind of orchestration, because we control what the backend is.

    But of course with WordPress, when we’re building for WordPress, we’re building for like 45% of the web. So the technical requirements are a lot more of a challenge. Yeah, I’m keeping a keen eye on that and I’m really excited to see how that progresses. Because, yeah, I think that’ll take Gutenberg to high Peaks, and will be something that a lot of different people building on top of the block editor, on top of the Gutenberg project will be able to utilize.

    [00:43:07] Nathan Wrigley: That was kind of like a roadmap question, but in disguise. Let’s just ask it outright. Just outline for us in the near future, we’re recording this towards the middle of February, so depending on how long it takes this podcast episode to actually make it out into the public, some of these things may have come a along already. But just outline roughly, maybe let’s go for six months, eight months, something like that. What’s the plan? What are you hoping to implement?

    [00:43:32] Steve Bruner: Well, our customers are always giving us ideas, right? So things do change like you mentioned. Our priority of right now is user roles and capabilities. Once that’s integrated, and that’s going to take a little bit because not only do we need to plan it out and how it’s going to work technically. We also need to make it super simple to implement, so clients can do this and feel comfortable that the right people are seeing the right data. So that is going to take a little bit of time.

    E-commerce would probably be our next big focus. Our clients want to start taking payments from their clients, right? The cleaning service is a great example. Right now the plan for her is to email a Stripe payment link to her clients, but we want to make things a little bit easier.

    Also that feature would, currently being done through Zapier. Which is an additional charge. So we want to bring that into Engine Awesome, where we can make it seamless and where our clients won’t have to pay any more for that.

    Those are probably the two major features that we want to roll out in the next six months. There are other things we want to do. We want to do, you know, we want to add scheduling. Again, a lot of our clients are service businesses. So scheduling is a big part of that, and they’re using services like Calendly, and if we can do something better or bring it into Engine Awesome , make it easier for them to use, then we want to be able to do that as well.

    [00:44:55] Nathan Wrigley: The introductions at the top of the show made it pretty obvious that you’ve got a history of giving back to WordPress. So, forgive me if this question sounds ill placed. But given that you are leveraging quite a lot of the Gutenberg project to build out your SaaS app, I’m just wondering what your posture is in terms of giving back from Engine Awesome. Back to Gutenberg. Again caveat emptor. Sorry, I know that you both do more than enough already, but I just wondered if that was part of the ethics of the business.

    [00:45:28] Timothy Jacobs: Yeah, I’m a big believer in that I think the Gutenberg project gets better the more different use cases that we have. Historically, my contributions to WordPress have been mainly focused on the REST API, and how Gutenberg interacts with the REST API. But I hope to be able to dive in more and more into the core Gutenberg project.

    So I think being good stewards of the open source community is a key aspect to building on top of an open source project. Both from, this is the best thing to do from a kind of community standpoint. But I think also everyone should really be thinking about how they contribute back to Gutenberg. So that we have a say in shaping how Gutenberg moves forward.

    There’s a lot of work to do, and we all have different pet features or things that we might want to have changed or improved in Gutenberg. And, really the long and short of it is that there’s more work to do than there are contributors to do the work. So the more of us that can contribute back to the Gutenberg project and the WordPress Core project, the faster we’re all able to go.

    [00:46:39] Nathan Wrigley: Thank you, Steve. Anything there?

    [00:46:42] Steve Bruner: No, Tim said it all. Tim said it best. He’s been a core contributor for a long time. Our goal from day one, like you mentioned, we’ve been contributing to the WordPress community in both code and education for a very long time and we want to continue to do that.

    [00:46:57] Nathan Wrigley: Yeah, that’s a nice answer to hear actually. That’s very heartening. Thank you. Should anybody have been listening to this podcast, had their interest peaked. They’re either interested in talking about what you did with Gutenberg from a technological point of view, because maybe they’re thinking of adopting Gutenberg in their own platform. Or they just want to actually find out what they can do with Engine Awesome themselves.

    I don’t know if you want to answer this question separately or combined, but where is the best place to get in touch? Is it a contact form? An email address? Is it, dare I say it, Twitter.

    [00:47:30] Steve Bruner: Right now our website is really the best place to contact us. So engineawesome.com. On the homepage if you are interested in signing up, or just getting on a Zoom call with me to learn more, there’s a input right there where you can put in your email address and sign up for that.

    And we also have a contact form where if you have questions about Gutenberg and how we did this and you want a more heavy developer talk, you want to chat with Tim, then that’s the place to let us know.

    [00:47:59] Timothy Jacobs: Yeah, you can also always find me on the make make dot WordPress Slack. That’s also a great place to reach out.

    [00:48:05] Nathan Wrigley: Okay. Thank you Timothy Jacobs and Steve Bruner. Thanks for joining me on the podcast today to talk about Engine Awesome. I really appreciate it.

    [00:48:13] Steve Bruner: Thank you, Nathan. I really, I really enjoyed this.

    [00:48:15] Timothy Jacobs: Thanks for having us.

    On the podcast today we have Steve Bruner and Timothy Jacobs.

    Steve has been active in the WordPress community for the past 17 years. He’s a WordPress developer, co-organizer of the WordPressNYC Meetup, and has organised many WordCamps in New York City.

    Timothy is a WordPress Core Committer for the REST API, and has been a WordPress developer for over ten years. At StellarWP, he leads development of the iThemes Security plugin.

    What brings them together is that they’re both founders of a SaaS app called Engine Awesome, where Steve is the CEO and Timothy is the CTO.

    What has this got to do with WordPress, you might ask. Well, they’re here today to talk about Gutenberg, but not how you might expect. It’s Gutenberg outside of WordPress, but Gutenberg nonetheless.

    Like all of WordPress, Gutenberg is open source. You are free to download it, modify it, and use it in whatever way you like. When Steve and Timothy began working on their new project, and needed a way for their clients to interact with it, they found Gutenberg was the perfect tool for the job.

    We talk about what benefits they’ve gained by using Gutenberg. How it’s saved them time, and how it’s fast becoming a stable and mature product, which is easy for non-technical users to understand.

    We get into the details of which parts of Gutenberg they used, and which parts were not suitable for their app. They’ve been building their own blocks which work well in the UI, but which are more suited to the kinds of data that they’re gathering.

    The discussion then moves onto what Awesome Engine actually does. It’s an app builder in which you can construct your own data containers and theme them so that it displays in any way you like. They tell us about the features which they have so far, as well as the items which are on their roadmap.

    Towards the end, we talk about their commitment to continue contributing back to the Gutenberg project, and how they feel that it’s in everyone’s interest if the project gets better from any updates that they have made.

    If you’re looking to build your own SaaS app, or you’re just curious about how Gutenberg is being deployed outside of WordPress, this podcast is for you.

    Useful links.

    Laraberg

    Gutenberg for Drupal

    Engine Awesome has a new look! – blog post

    Airtable

    MongoDB

    Digital Ocean’s managed database service

  • #71 – Nathan Ingram on How To Manage Contracts With Your WordPress Clients

    Transcription

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case how to manage your website client contracts.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the show, I’m very keen to hear from you and hopefully get you or your idea on the podcast as soon as possible. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today, we have Nathan Ingram. Nathan is the host at iThemes Training, where he teaches WordPress and business development topics via live webinar. Based in Birmingham, Alabama, he has been working with clients to build websites since 1995.

    He’s also the creator of MonsterContracts, which helps WordPress professionals create contracts for their client work.

    If you’ve worked directly with clients, then you’ll know that things don’t always go according to plan. Assets might not be delivered on time. The client does not respond to your emails. The expectations of the client begins to creep away from the original proposal.

    Whilst there’s unlikely to be a perfect system to ensure that all projects run according to the plan, you can protect yourself from some of the worst aspects. And for this, you may need a contract.

    Nathan is on the podcast today to talk about why he thinks contracts are an essential part of any client facing WordPress work.

    We begin by talking about how the contract is designed as a tool to bring clarity to both parties. You, the website builder, can set out the constraints within which you work and the client can understand what they can, and cannot, expect from you. Nathan thinks that setting these expectations before the project begins leads to fewer problems later on.

    We talk about the fact that contracts don’t need to contain overly complex legal language, but they do need to be checked by a qualified legal professional before they’re deployed.

    Nathan also explains how he’s refined his contract over the years, tweaking the wording and the structure, depending upon the project at hand.

    We then get into what you can realistically do should your client breach the contract. Are you able to turn off their website, or withhold work that you’ve completed? Nathan’s not really in favour of sending in the lawyers as soon as something goes wrong. Rather trying to resolve any conflict through better communication.

    It’s an interesting conversation, which makes contracts seem less adversarial and more about ensuring that your WordPress website projects run as smoothly as possible.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

    And so without further delay, I bring you Nathan Ingram.

    I am joined on the podcast by Nathan Ingram. Hello, Nathan.

    [00:04:07] Nathan Ingram: Hey Nathan, how are you?

    [00:04:08] Nathan Wrigley: That’s strange. I’ve not had that before. Two Nathan’s on the podcast today. Very different levels of experience in the subject that we’re going to be talking about. Nathan Ingram is here today and he’s going to be talking to us about the legal aspects of hiring clients.

    You might describe it in one word as contracts, I guess. And there’s a whole treasure trove of things that we’re going to unpack there. But before we do that, Nathan, if anybody hasn’t heard of you before and hasn’t seen the things that you are doing online, would you just spend a few minutes introducing yourself? You can go back as far as you like but, give us yourself in the WordPress context.

    [00:04:44] Nathan Ingram: Yeah, sure. So I’ve been working with WordPress exclusively since right around 2010. I run a small agency down in Birmingham, Alabama. I’ve been working with clients since 1995. So I’ve been around the webspace for quite a while. I also am the host at iThemes Training. So we do live training webinars three days a week through iThemes. And then I also do some business coaching, and I have a product called MonsterContracts.

    [00:05:08] Nathan Wrigley: Tell us about the iThemes thing for a minute, because I know you do trainings over there. How did that all come about? Was it like a happy coincidence that you ended up doing that? Were you making content, training content, elsewhere that got you into that position?

    [00:05:22] Nathan Ingram: No goodness. So it’s really an interesting story and we could take a whole , a whole episode on how do people find their way in the WordPress community? So for me, iThemes was actually iThemes training at that time. Early on it was called webdesign.com. They had leased that really awesome domain name.

    And it was where I learned WordPress. At that point I was sort of in a, the Macromedia ecosystem, and I had resisted WordPress for quite a while. Decided this is coming and I’ve got to go with the flow and move into WordPress, because a lot of my clients were looking for WordPress sites. Or sites they could log in and edit themselves. I found iThemes as a theme company, and the training went hand in hand, and that’s where I learned WordPress. And gradually over time, I started presenting one or two webinars and then gradually rolled into the presenter role.

    [00:06:08] Nathan Wrigley: That’s nice. And so you do that regularly, three times a week. You go live and give trainings about a whole range of different subjects, right?

    [00:06:15] Nathan Ingram: Yeah, like just yesterday we did our monthly news roundup on iThemes training. So look at the news in the WordPress world. Particularly from the perspective of people who build and manage websites. That’s really our audience on iThemes training. What news is important for people who do what I do.

    [00:06:29] Nathan Wrigley: Okay, so that’s really excellent. Unfortunately, it’s not the topic that we’re going to be talking about today. We’re talking about one of the areas, I think in web design that really can cause the blue touch paper to be lit, and the firework to go off. This is the whole thing of relationships with clients and the boundaries that you set, and whether you should have contracts, and whether you should be getting involved with lawyers and things like that.

    And there are very few parts of the business that I used to run, which would cause me to become upset, irritable, and in some cases quite angry. But relationships with clients could do that. It’s quite unique, isn’t it?.

    [00:07:15] Nathan Ingram: Oh, it really is, and I’ll tell you, it is certainly one of the common challenges that people who do WordPress things run into. You go to WordCamps, back when we used to have those things, so we actually just had our WordCamp Birmingham two weeks ago, and it was wonderful to see people in person. But when you get a group of people who work with clients around, you know, a table eating lunch at an event like a WordCamp, inevitably the conversation turns to bad clients and everybody has a story.

    [00:07:40] Nathan Wrigley: Yeah, it’s just one of those things. I’ve got a whole litany of stories. On the whole I think I was able to manage this scenario fairly well, but there was a lot of things probably that I shouldn’t have done. So I gave way in many cases because I believed that the things that the client was asking for didn’t really push the boundaries too far, although they certainly stepped over the expectations that I had.

    But your premise really, the reason why you’ve been getting into this and talking about this is because you want to prepare people and educate people to give them a kind of legal framework. And you describe it in terms of boxing in a client if you like. That’s probably too harsh a word.

    You go about it in much more conciliatory language than that. But the point is, you are educating people to get themselves into a position where they’ve got some piece of paperwork, some contract. Something written down somewhere where you can all go back and say, okay, these are the boundaries, these are the constraints. If we step outside of these, one of us is at fault. So tell us a little bit more about your approach there.

    [00:08:47] Nathan Ingram: That’s a great question. So years ago I put talk together about dealing with problem clients. And the title of the talk was “dealing with problem clients, building fences around friendly monsters”. And it’s a book, actually now I turned that into a book on Amazon. But, it’s really positioning the client, every client as what I would call a friendly monster.

    Meaning they’re friendly, but they still have teeth. The idea is we need to build fences around the clients that we work with, because we never know what kind of person we’re dealing with. And the fences that I talk about are the systems and processes in our business.

    Four in particular. We need to establish clarity. We need to have good commitments between us and our clients. We need to have communication and documentation. And those four fences can show up in a lot of different ways depending on your particular business and how you work. And there may be additional fences you’d want to build, but those four at least have to be in place in order to have good ongoing client relationships.

    And a lot of those things show up in a contract. But they start as just part of your regular business system, the way you work, the way you deal with clients. Clarity, commitments, communication, documentation. And that’s where it all has to start. Like you’ve got to get your house in order before you can really bring in a good document, like a contract to, make your rules clear.

    [00:10:10] Nathan Wrigley: I think the clarity piece coming first is really intriguing. Because that was always the misstep that I felt I’d made. In that I was very often in a position where I felt that I had explained myself clearly, and assuming the clients were being honest when they were explaining their frustration with the way things were going.

    I clearly hadn’t done that. I maybe expressed it in a way which I understood, maybe that was too technical. And later down the road it became obvious that there was a complete disconnect between what I was trying to achieve, and what they, in their head, had got designed. And so yeah, the clarity piece, I think is perfect at the beginning, but also quite difficult to achieve. How do you, how do you advise that? What are some of the strategies that you’ve got in place around that?

    [00:10:57] Nathan Ingram: Yeah, it really is difficult, and one of the first things I think you have to realize is that agreement on the surface does not equal clarity. So, if there’s no meeting of the minds, like maybe we use technical jargon, or maybe the client doesn’t tell you everything at the beginning.

    I can’t tell you how many projects I’ve gotten into where the client, we’ll get three quarters of the way through the project, and they’re like, oh, well where do my clients log in? Well, wait, we haven’t talked about this at all. And in those sorts of situations you ask yourself, well, whose fault is that?

    And I would say it’s probably 50 50. And so one of the great skills that we can develop in in way, but specifically in our way of working with people on the web, is learning the skill of asking great questions. If you learn the skill of asking great questions, and continuing to ask until you reach that point of clarity. That skill can really set you apart from other people that are doing client work.

    Asking a question, asking why, and following up with additional questions until you really get down to the root of what the client expects. If you don’t do that, then oftentimes you can be saying one thing, the client can be saying another, and you’re both shaking your head up and down, but nobody is really clear on what we’re saying. Assumptions are made.

    [00:12:08] Nathan Wrigley: In the work that you do, do you typically do all of that client exploration work prior to beginning the build? And then in a sense, that process is closed off, and you go away and you take six weeks, whatever it takes to complete your initial first offering and then go back to the client? Or do you, do you encourage a more agile approach where you iterate with the client? I mean, I know that they’re completely different ways of doing things. Curious as to know what your process is.

    [00:12:36] Nathan Ingram: So it really depends on the complexity of the build. We try to get some understanding of that at the very beginning, when we’re trying to create the scope of work. If it’s a project we’ve done before, if it’s a simple, just a basic identity piece, a brochure site, that’s fairly simple.

    When you get into something that is a lot more complicated, maybe there’s lots of different content types, or you’ve got to do some really interesting thing with data. A lot of times what we’ll end up doing, and I picked this up from my friend Beth Livingston, a change budget. So adding a change budget into the original pricing, that as we go forward and the client gets more ideas where things are uncovered, that we didn’t realize, there’s some pre-approved money sitting there, that the client can say, okay, we’ll allocate some of that change budget to build this thing that we hadn’t talked about yet.

    [00:13:22] Nathan Wrigley: Yeah, we’re in such a curious industry as well, in that there’s not many things that I purchase that morph over time. You know, if I go into a shop and I buy some clothes, I’m just getting what I’m getting. I can see it right off the bat, and there it is, and I can hold it in my hands, and it’s either what I want or it’s not what I want.

    I’m not going to purchase that pair of trousers and then turned around a week later and said, actually, you know what? These pockets. I’ve been wearing these trousers for a couple of weeks now, and the pockets are not deep enough. Can we have an amendment to the pockets please? This curious idea of scope creep that creeps into more or less every project that I was ever involved in.

    Are you getting your clients, after your initial discussions then, are you getting them to a point where you draw up some contract which in effect puts the four fences around the friendly monster that you were describing?

    [00:14:12] Nathan Ingram: In our world we would call that the scope of work, which is part of the proposal. That comes from the original conversation. Or if it’s a complicated project, maybe there’s a discovery phase that happens first to really flesh out, what is the scope of work? What are we trying to accomplish in this project.

    And then depending on the complexity of the project, the longer, or the more complex a project is, the greater chance of scope creep. Or honestly, the longer a project takes, because the client delays on content or something else. The longer a project takes also, you tend to have scope creep.

    When you talk about scope creep, people’s eyes roll. They hate scope creep. But I’ll tell you what, I love scope creep as long as there’s corresponding price creep, right? If you want more things, that’s great. It’s just we can’t do more for the same price. In your analogy about, we don’t use the word trousers.

    [00:15:00] Nathan Wrigley: Oh yeah, you use pants don’t you? I apologize.

    [00:15:02] Nathan Ingram: Yeah. When you’re talking about something like that, it’s a little bit different because, well some people sell websites more as a product rather than a custom service. We’re more on the custom build side. Everything we do is bespoke. But you know, if you’re selling websites as a service, that is a good analogy because you’re in package three and this is what it comes with and this is your pair of pants.

    But for us it would be more like, I’m hiring a contractor to come in and do a remodel on a kitchen .And this is kind of what we talk about at the beginning, but as we go, maybe we had a problem we didn’t anticipate. Or maybe my wife sees something on television that she wants to add. And so we want to add to it and we change it along the way. That’s really a closer analogy, I would think, to a custom website.

    [00:15:44] Nathan Wrigley: It’s pretty clear that the audience for this podcast is pretty broad and deep. In other words, there are all sorts of people listening to this doing all sorts of work around the WordPress space. Some of them very new to WordPress and website building at all. Some of them just doing it for their own hobbies. Other people just getting into building websites for the first time.

    So let’s speak to that crowd first. The crowd who really are just embarking on a career. They’re scoping out whether they wish to build websites for other people and charge for that, and make a business out of that. Let’s speak to the importance of a contract, because it may be that when you’re starting out, you’re just doing this with friends and we know that that can turn south quite quickly.

    So, and also, you know, you may be encouraging businesses in your local area to come on board and they’re going to be expecting something like a contract. Is this an essential component of the makeup of a web designer? Do you truly need a contract? Or is there any realistic situation where it’s okay to begin work on a website, charging a fee without some legal protection?

    [00:16:50] Nathan Ingram: Wow, what a great question. For years I worked without a contract. I just had a proposal with a scope of work and a price, and you pay me, I build the thing and there it goes. Then I started running into problems. Expectations that were never really talked about anywhere. For example, oh wait, this would’ve been like many years ago.

    But at that point it was maybe Internet Explorer 6 was the browser of choice for everyone. And the person would say, wait this is not working on my Internet Explorer 4. Well, we don’t design for older browsers, we design for newer browsers. And there was great difference in rendering between those two.

    These are the sorts of things that you don’t think about until you have a problem with a client. What I like to say is you don’t need a contract for good clients. You need a contract for bad clients. But my goodness, it’s hard to tell them apart at the beginning. So every client gets a contract. And my contract is mostly plain English, and virtually every paragraph in that contract, aside from the necessary legal constructions, everything in that contract is there because I had a problem one time with a client. That now gets added to the contract for the next time.

    [00:17:59] Nathan Wrigley: I was very much like you in that I began way back, and it was long before IE6 in fact. I remember writing that into my contracts at one point. We are not supporting IE6. It was exactly the problem you described. I had happily breezed through multiple websites. No problem at all, everything was fine. I had a client who simply was able to push harder than anybody I’d come across before. In other words everything that I delivered, they would either reject or request it to be entirely different.

    So this whole notion to me of scope creep and the client who refused to accept that anything was finished, came along. And it really was at that point that I started to look around and try to protect myself. So, I would imagine that your advice is really, it doesn’t matter on what level you’re doing this. You need some kind of legal protection, right?

    [00:18:51] Nathan Ingram: So I would even take a step backwards. You need a consistent process that you use for every client, every project, every time. And that process needs to be documented somewhere in something that you and the client agree to. Call it whatever you want. Call it a contract. Call it, as we do, a master services agreement. You could put it in your proposal, but just have some place where everybody’s agreeing to the process. That’s that piece of clarity at the beginning where we are clear on how this is going to proceed.

    Where we get into trouble is where we, we think, well we just sort of do every project differently and there’s not really a consistent process. And so the client is able at that point to dictate how the project goes. Will have at some point, you know, some level of control over your world, as long as you’re building that website. Instead of realizing, okay, this is the best way to build. We’re going to document this process out, and have the client agree to it in a contract.

    [00:19:47] Nathan Wrigley: I guess whenever I’ve read legal contracts before, whether they’re for my car insurance or what have you. I’m always confounded by the language used, within moments of beginning the reading of it. I’m coming across, not only words which I haven’t encountered before, but the sentence construction is entirely bizarre.

    In other words, it can be read by a lawyer. Sometimes I’m confused as to whether or not it’s written deliberately to be hard read or whether or not it’s the most expedient way of hammering something down perfectly. I can never parse that. Either way, I’m left confounded.

    So given that lawyers very often end up with this language, which is impenetrable. And you mentioned that your contracts are in plain English. Is it possible to nail things down, absolutely watertight with plain English? And do you feel yourself equipped to do that? Or is this really the domain of a lawyer? Do we need to get a lawyer to go through your contract and inspect it to make sure that in every scenario it’s having your back?

    [00:20:59] Nathan Ingram: So, just first of all, I’ll answer this from my perspective as a person who’s been working with clients, doing web things for over 25 years. I’m not an attorney. This is not legal advice or anything like that. But my experience has been sort of a blend of both.

    It’s important to have good, practical experience working with clients and knowing what the problems are. But you also do need the legal language. Because if the worst thing happens and you end up in court with a client, there’s a reason that attorneys write things the way they do. You know, this is language that has been proven out and so forth.

    And so if you take a contract that is exclusively plain English, you can get tied up with defining what the meanings of this word and that word and so forth are, and it turns into a mess. So, if you went out today and you did a search for a web design contract on the web, you would find two types of contracts in general.

    You would find some that are just absolutely plain English with no legal constructions whatsoever. And those are okay. They do establish clarity, or give you kind of a template to establish some clarity. But they don’t have the legal protections. On the other side, it’s like the total opposite end of the spectrum. Contracts that are a hundred percent legalese, and I don’t understand what some of these things mean. And this is what you were talking about a bit earlier. And I’m not sure if that really gives clarity to the client, because nobody really knows what any of this means unless you’re an attorney.

    And so what I found to be the best approach, and this is what I’ve done, is I began years ago explaining our process. Explaining what we do, what we don’t do. Explaining some of the issues like browser compatibility, and what happens if you hire a digital marketing person that comes in and they break your website. Are we responsible for that because we’re managing your website.

    All of the bad experiences I’ve had with clients, I started putting those things down in a document and then I gave that to an attorney and said, okay, make this legal. And so they added all the necessary legal constructions, and patched the holes. Over time this has become my agency contract, and that’s what I ultimately turned into MonsterContracts.

    [00:23:02] Nathan Wrigley: With your contracts, did you find that the nature of the project at hand, in other words, the one that you’re working on right now. Given that each client website is slightly different and it may have different constraints. It may need, I don’t know, let’s imagine, a WooCommerce store or something like that. We really are getting into a completely different variety of website. Or it may be a simple brochure site. Or it may be that there’s a bespoke plugin, for example, has to be written for that website.

    Do you advise taking those contracts that you’ve had written, or rather inspected by lawyers, do you take them back and get them to look, more of a scan through each time and append to it, the bits and pieces that are needed? Or have you settled on a contract which you think is broadly good enough to fit any situation?

    [00:23:50] Nathan Ingram: It’s a great question. So this exact situation is why I recommend a two document approach. So we have a proposal of services that deals with the scope of work and the price for every individual project. And those are going to be different every time. But then we have a master services agreement, or a contract, that has the rules of the road for every project. These don’t change. And so we present those documents together.

    So the contract that the master services agreement covers the process. All these things that we do and timeframes, and what happens if you don’t pay and, here’s how the website management works, and we don’t guarantee results for SEO.

    All these things that need to be in a contract that don’t change from project to project, are there in the contract. But then the scope of work of we’re going to build this plugin, or we’re going to add a store, we’re going to do whatever. Those are in the proposal, which is the scope of work and the price for that individual project.

    [00:24:43] Nathan Wrigley: Right, okay, that’s an intriguing separation. Yeah, so two different documents. One which is more bespoke and one which is more generic and you can reuse over and over again.

    [00:24:53] Nathan Ingram: Exactly.

    [00:24:54] Nathan Wrigley: So, given that we’ve got a contract. Given that it’s been written by a lawyer, and there may be aspects in there that are impenetrable to us. I guess there’s always going to be a need to go back to the lawyers. I can imagine the fees of this starting to tick up quite quickly actually. Because if a client comes back to you and you believe they’re in breach of the contract in some way, but the contract is difficult to read, it’s in that legal language. That’s an important thing to do, isn’t it? You really do have to understand the ins and outs of your contract.

    So given any scenario of inverted commas, wrongdoing by the client, you are able to say to them with confidence, look, this is what you signed. This is what this clause in the contract meant. In other words, you have to know what it says in plain English in your head. Otherwise you can’t really enforce it, because you wouldn’t be sure what you were able to enforce.

    [00:25:47] Nathan Ingram: Right, and this is why if you were to open my agency contract, or if you were to look at MonsterContracts. You would see things like payment terms, and they’re all in plain English. Again, this is why I said earlier, I want to have my system documented ahead of time.

    Like I want to know, internally, this is how we deal with late payments. This is what happens if the client disappears during a project, all these things. We have our policies internally for this. Those are then put into the contract in very plain wording that can be easily pointed to. There have to be legal constructions, but these are, they’re really at the end of the document and they don’t pertain, nearly as much to these practical issues that come up with the client.

    [00:26:28] Nathan Wrigley: Do you ever, so this is a question more directed at you personally, given that you’ve got all these contracts and you’ve thought all of this through. Do you ever let things slip, in other words, you’re having a conflict internally. Part of you saying, I know that this client is now in breach of what the, not only the spirit, but the letter of the contract said. But I’ve got a bit of a spidey sense that I can let this one go. It feels like it’s going to be all right. Because there be monsters down there.

    And it’s so easy. I did that and probably continue to do that quite a bit, because sometimes I feel that if I push the legal button, I really have transformed everything. I’ve suddenly gone from it being a fairly friendly relationship, albeit fraught at times. To a really adversarial relationship where the lawyers are getting involved and so on. So I’m just wondering whether or you permit yourself to ignore your contracts in some scenarios.

    [00:27:24] Nathan Ingram: Oh, what a great question. So the answer to that question, it revolves around emotional intelligence, right? you have to make a judgment call on, is this a situation that is worth really enforcing the contract or not. And honestly, many times, let’s just say, here’s the situation. The client, we’ve been waiting for three months for the client to supply assets that are needed to build the website, and that happens all the time, right? Clients delay, delay, delay for content, and photography and everything.

    So, in the contract, it says if we haven’t heard from you in 30 days, then your project is suspended. And there’s some things that happen as a result of that. Now, can we choose to change that? Sure, but oftentimes what will solve that problem is a simple email to the client. Hey, we haven’t heard from you in the last 30 days. At this point your project is about to go into suspended status. And this is what that means.

    We explain in the contract. And just having a clarifying email like that can oftentimes shake up the client and get them refocused on the project. If it doesn’t, then you have to make a judgment call on, is this a salvageable project or not?

    [00:28:34] Nathan Wrigley: Yeah, I feel like I’ve encountered many different interpretations of this. On the one hand, there’s a lot of people out there in the wild who really are proponents of, look, the minute it goes wrong, start lawyering. Just protect yourself. Get the lawyers involved. You cease communication with the client and start to go through the lawyers.

    It’s this idea of, it’s not working out. I need you to do what you’ve agreed right now, otherwise it doesn’t work. We also hear constantly about firing clients and the joy that that can bring.

    But on the other hand, I feel that, like you said, you have to judge off your own instincts sometimes whether there is a legitimate reason behind there. And that has happened to me. You know, I’ve had clients that have not delivered things, and then it turns out there’s not only a plausible reason, but a reason, which if it were me in their shoes, I would desperately want the web designer to understand my crisis.

    Something personal has happened, some event in their life has meant that they literally have been away from the computer for weeks on end. And so it’s not really their fault. I guess the answer is use your judgment. Invoke the spidey sense, and figure out which is the best way to proceed.

    [00:29:42] Nathan Ingram: For sure. I mean, we’re dealing with people here, right? And so my default dealing with people is generally grace. I’m very gracious with people. Understanding about issues that come up. On the other hand, it’s important to have a document that protects you. If you get to the point where you have to fire the client.

    That’s a great conversation. And, and you hear a lot, especially on social media and Facebook groups and places like that. Oh, we got to fire the client. This whole discussion, right? But that’s complicated. If you want to fire the client, can you even do that? Do you have a contract that specifies what happens if you want to terminate the relationship?

    That’s where having a good document that protects you is critical, because you know at some point, oh, the client didn’t pay me, so I’m going to turn their website off. Well, guess what? If you just turn their website off for non payment, and they haven’t agreed to that stipulation, then you can get sued for that.

    Well you didn’t give me due process and whatever. And you can find yourself in a lot of trouble if you don’t have a good document that protects you. So my advice is always have a great contract that is weighted towards you as the service provider, and then you can choose to be gracious when you want.

    [00:30:44] Nathan Wrigley: So let’s get into that bit. You were mentioning about switching the website off. So it’s almost like the sanctions piece. What do you have in your arsenal as a web designer, which you can bring to bear should you need to apply a little bit of pressure to make sure that things are moving? So I’m describing a scenario now where things have clearly gone south.

    We’re definitely in the territory of miscommunication has been heaped upon miscommunication. We’re at the point of almost falling out. Communication is breaking down, and so we now need to bring out the big guns, if you like. What have we got? You mentioned turning off the website, that’s obviously one thing that we could do, given that that was in a contract.

    I’m thinking we could refuse to do any additional work. There’s obviously the refusal to communicate unless you go through lawyers at this point. What are the kind of things that you would put in your contracts that you would allow yourself to have as an option?

    [00:31:40] Nathan Ingram: So it would obviously depend on where we are in the process of the project. But if you’re in the middle of building the site, the client is texting you at 2:00 AM, or whatever. This is clearly not going to work, and we’ve tried to communicate and tried to request the client to change their behaviour, and they just simply won’t do it for whatever reason, and you need to pull the plug on the project. Then, you know at that point, at least my contract says, we as an agency get to evaluate the work that’s been done and say, okay, 78% has been completed and so you owe this much more.

    Or if we’ve already received full payment, we’ll refund that much or whatever. You need some process by which you can mitigate or decide who gets what at the end of this. So if you’re in the middle of the project, and you want to pull the plug, somebody has to figure that out.

    If it’s a client that’s maybe in a management phase and they’re just not paying their bill or they’re asking for too much or whatever, it’s always a conversation. What’s going on here? And is there something we don’t understand about this? But, at some point you have to have an agreement that if you don’t pay your bill within certain time, then we do suspend the website from view.

    [00:32:46] Nathan Wrigley: I guess there is also a point where you have to cease communication through anything other than the lawyers. Because at some point any stream of email going left, right, and center has to be mediated by a professional who’s removed from all of this.

    [00:33:03] Nathan Ingram: Yeah, you really do. And you know, we first tried to do arbitration, just to try to keep things out of court. That’s just a personal preference. But at some point you have to do that. Now, thankfully I’ve never even gotten close to anything like that, and I’ve heard horror stories of where it’s gotten to that point.

    You know, a lot of this is, as you work with clients and you have good client experiences and bad client experiences. You start to develop, like you said earlier, this spidey sense. This radar of early on, like before you even sign a proposal with a client, getting better at filtering out the bad clients at the beginning.

    Hopefully over time that becomes part of this, where you don’t have nearly the issues. Early on I had bad clients. They would take advantage of me. they didn’t want to pay. They wanted to pay a just a little bit, not really what the work was worth.

    They would constantly second guess and question my professional decisions. It was just terrible. I began to realize there are better clients out there and, not let those difficult clients in our world to begin with.

    [00:34:02] Nathan Wrigley: It’s interesting as this podcast has gone on, we’ve concentrated on the negative aspect of contracts, in the, you know, we’re protecting ourselves. This horrible thing could happen, so make sure you’ve got some protection. Oh, and this horrible thing could happen. But really, it’s the opposite, isn’t it? The contract is there to give you peace of mind. It’s to create a sort of positive scenario.

    And so hopefully you won’t find yourself in these positions. If the contract is robust enough, everybody signed it, read it, understood it, then those boundaries are in place so that these disasters don’t occur. So there’s a bit of silver lining on this cloud.

    [00:34:38] Nathan Ingram: Oh, it absolutely is. There’s this old story about this mother who’d warned her children about playing next to the road because they lived next to this busy highway. And oh, don’t get close to the road because, you know, you could get hit by a car or whatever. And so the kids would not go just a few feet from the house because they were terrified of this road.

    And then they realized, well, our kids aren’t even playing in our yard. So they put up a fence between the yard and the road. And the kids then could play within the boundaries of the fence and weren’t afraid of the road anymore. And that’s just a little example of put up a fence, a contract, and it really frees you to work better with clients.

    And in my experience, it’s if a client out of the gate, if the client pushes back against some of the things in our contract, it’s a huge red flag that we probably don’t want to work with this client, just right away. Because everything that is in our contract is there for a reason.

    I tell the clients that. It’s a rather long document, but everything is there for a purpose. And if you have questions about it, I’m happy to answer those, you know, happy to talk through why we do this. But it’s there for a reason and it really establishes the boundaries of our relationship.

    And the remarkable thing about all of this is, people look at a contract, well, I’m afraid to get my clients to sign this, it’s really long or whatever. The good clients have no problem signing contracts like this. They welcome it. It’s a mark of your professionalism that you’ve thought through your business well enough to have a well crafted document that governs this whole process of us working together.

    [00:36:03] Nathan Wrigley: You’ve obviously given this a great deal of thought in the past. You live in the United States and you mentioned Alabama. Obviously America’s a tapestry of different states with laws and, honestly I don’t understand that a little bit. But in the UK we have UK law and then there’s EU law, and then obviously there’s law in other jurisdictions.

    This, I suppose is something which we might mention right now, towards the end of our recording. You’ve got to have that in mind as well. It really does matter where you are and where the clients are because I guess you’ve got to think about the law. Should it go wrong, are you protected correctly given where the client is and where you are?

    [00:36:40] Nathan Ingram: Yeah, for sure. There’s a lot of local laws that govern things that you wouldn’t think about. And that’s why it’s critical to have a local attorney that understands technology and things like intellectual property and these sorts of things, to take a look at whatever document you have.

    One of the biggest challenges with MonsterContracts was, okay, I’ve got this document that I have a hundred percent faith in for my work here, and really even state to state. There are very few things that would have to change from state to state, using in the United States.

    But then we started getting some people buying the product internationally. And I began to wonder, wow, how is this going to work? I did have some experience. I had a coaching client, somebody that I was working with in business development who lived there in the UK. I provided her a copy of the contract and she had it vetted through a local attorney there.

    There were just very few changes. So, the way that at least my contract works is most of it, and I would just, pulling a number out of the air, say 80% of the document is just plain language about processes and things like that. And the legal language is at the end. So the attorney in the area, whether it’s internationally or locally in a different state or whatever, they could just substitute the little bits of standard legal language at the end and make it work wherever you are. And we now have people who’ve bought MonsterContracts all over the world and they’re having that experience where the attorney can review it with maybe one or two hours of time. It works great for their location.

    [00:38:05] Nathan Wrigley: So just give us the quick elevator pitch of MonsterContracts. It sounds like that it’s a service that you can essentially log in, pay your subs, and then you can extract from it contracts, which hopefully you can then use.

    [00:38:19] Nathan Ingram: That’s basically it. And so again, this is, it’s based on my contract that over 25 years of working with clients, I’ve gradually made better until it’s virtually bulletproof, I think, in my opinion. The MonsterContracts is simply a Word document. You log in, you purchase the document. You take this. You tweak anything that’s there to match your processes or the, you know, if you don’t do things in the same order that the contract specifies, change that around. Plain simple wording. And then the recommendation is always take that to your local attorney to allow them to, you know, run through it and make any changes.

    And universally the response has been, one or two hours of time and it’s done. So, for most people they’re going to have one of the two types. So if they’re using a contract, they have the type that’s just plain English and full of holes, or it’s just a bunch of legalese that no one understands.

    MonsterContracts it addresses the specific situations that we encounter as web professionals, and it provides the cover that you need to grow your business. It addresses all the things that we deal with in client work.

    [00:39:16] Nathan Wrigley: I think you’ve got a system whereby you can submit amendments that you’ve had made. So let’s say for example, in my case, the UK. I could make amendments and then submit them back to MonsterContracts so that other people can benefit from that as well.

    [00:39:32] Nathan Ingram: Yeah, exactly. So we have the ability to do that. That’s an area of MonsterContracts that I’m really working on growing this year. We haven’t had as many members do that as I had hoped originally. And so that’s one of our goals this year is to expand those revisions. MonsterContracts is a subscription, just to keep access because we do have the contract vetted by an attorney annually.

    And, there are usually at least a few changes to the contract every year to just keep up to date with things that are happening in client work. The subscription gives you access to those changes as well as any revisions that people upload. And if you upload a revision that’s accepted we credit you for that year’s cost.

    [00:40:06] Nathan Wrigley: So a scary subject hopefully somewhat tamed by having contracts. Nathan, thanks for chatting to us today and putting our minds at rest and giving us some advice. If the listeners to this would like to get in touch or figure out where you are or begin a chat with you, what are the best, some of the best places to find you online?

    [00:40:26] Nathan Ingram: Yeah, sure. So, monstercontracts.com is, the place to find the MonsterContracts product. There’s a great contact form there if you want to reach out to me about any contract related questions. My coaching website is nathaningram.com. That is available out there for coaching work or questions around that subject. And I’m online three days a week with iThemes training, at training.ithemes.com.

    [00:40:48] Nathan Wrigley: Nathan Ingram, thank you so much for chatting to us on the podcast today. I really appreciate it.

    [00:40:52] Nathan Ingram: Thanks, Nathan. I enjoyed it.

    On the podcast today, we have Nathan Ingram.

    Nathan is the host at iThemes Training where he teaches WordPress and business development topics via live webinar. Based in Birmingham, Alabama, he has been working with clients to build websites since 1995.

    He’s also the creator of MonsterContracts, which helps WordPress professionals create contracts for their client work.

    If you’ve worked directly with clients, then you’ll know that things don’t always go according to plan. Assets might not be delivered on time. The client does not respond to your emails. The expectations of the client begins to creep away from the original proposal.

    Whilst there’s unlikely to be a perfect system to ensure that all projects run according to the plan, you can protect yourself from some of the worst aspects, and for this, you may need a contract.

    Nathan is on the podcast today to talk about why he thinks contracts are an essential part of any client facing WordPress work.

    We begin by talking about how the contract is designed as a tool to bring clarity to both parties. You, the website builder, can set out the constraints within which you work, and the client can understand what they can, and cannot, expect from you. Nathan thinks that setting these expectations before the project begins leads to fewer problems later on.

    We talk about the fact that contracts don’t need to contain overly complex legal language, but they do need to be checked by a qualified legal professional before they’re deployed.

    Nathan also explains how he’s refined his contracts over the years, tweaking the wording and the structure, depending upon the project at hand.

    We then get into what you can realistically do should your client breach the contract. Are you able to turn off their website or withhold work that you’ve completed? Nathan’s not really in favour of sending in the lawyers as soon as something goes wrong, rather trying to resolve any conflict through better communication.

    It’s an interesting conversation which makes contracts seem less adversarial and more about ensuring that your WordPress website projects run as smoothly as possible.

    Useful links.

    iThemes Training

    MonsterContracts

    WordCamp Birmingham

    Nathan’s “Dealing with problem clients, building fences around friendly monsters” webinar.

    Nathan’s website

  • #70 – Steve Persch and Brian Perry on How Hosting Is Changing

    Transcription

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, the past and future of website hosting.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the show, I’m keen to hear from you and hopefully get you all your idea on the podcast as soon as possible. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today, we have Steve Persch and Brian Perry. They’re both employed at Pantheon, an enterprise website operations platform. And they’re here to talk about the evolution of website hosting.

    Back when the internet started, hosting was a fairly straightforward enterprise. You created HTML files and uploaded them to a server. That was it. An HTML file was a page.

    Server-side technology such as PHP came along, and the picture became a little more complex. Web pages needed to be constructed on the fly. Databases were thrown into the mix, and the complexity increased. Add in the different languages that you could write your code in, and the server configurations. The CMS that you choose also plays into this mix. Now we’ve got CDNs, headless, React, Gatsby, Node.js and much more. Is it even possible for the non-technical to have any understanding of where their website is?

    Steve and Brian talk about how they got into the hosting space, and what’s changed over the years. We address what Pantheon is doing with WordPress and Drupal.

    We discuss how headless can be difficult for content teams, given that there’s a disconnect with hitting the publish button and that content going live on the site.

    What’s certain is that there’s no end in sight in terms of the rate of innovation in the website hosting space. What’s popular today might not be several years from now. And so it’s a timely discussion of what Steve and Brian see as the best bets for the future.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

    And so, without further delay I bring you Steve Persch and Brian Perry.

    I am joined on the podcast today by Steve Persch and Brian Perry. Hello.

    [00:03:37] Steve Persch: Hello, Steve Persh here. Happy to be here.

    [00:03:39] Brian Perry: Yeah, Brian Perry also really excited to chat.

    [00:03:42] Nathan Wrigley: Well, thank you for joining me on the podcast today. We’re going to talk about something, and I seem to have said this sentence much more often recently, about something that that really is a mystery to me. You are going to school me in all sorts of ways about something that I’m really not that familiar with, and that is all about how files get served up. Where are our website files being kept? Where are the computers? Where’s the infrastructure, and how much more complicated it has become over the last 10 or 15 years.

    Before we begin that, I think we’ll take you in order. I’ll go Steve first, if that’s all right? I’m wondering if both of you can give us a little bit of orientation about who you are, who you work for. Your history with technology and possibly WordPress in particular. So yeah, we’ll launch that with Steve.

    [00:04:28] Steve Persch: Sure, so Steve Persch here in Minneapolis, Minnesota. I’m the director of technical marketing at Pantheon. We’re a website operations platform for Drupal, WordPress and now front end frameworks, which is, much of what, thinking about that question of what computer makes the website.

    I’ve been in the web space for a while now. I first started making websites, first semi-professionally, and then professionally in the early days of WordPress. I built some of my first professional websites in WordPress 2, back in 2006. Then for some of the sites that I wanted to make, that took me into the Drupal world. And now in Pantheon, we play in both of those worlds, in the lamp stack, and as Pantheon is aiming itself at running extraordinary websites, as we like to say, the best possible websites. We see that that requires us to step more fully into the JavaScript centric front end framework ecosystem.

    [00:05:23] Nathan Wrigley: Well thank you Steve. That was great. We’ll hand it over to Brian to do a similar job.

    [00:05:28] Brian Perry: I’m Brian Perry. I’m a staff software engineer at Pantheon. What I’m focusing on at Pantheon is leading a project we’re calling Decoupled Kit, which is a set of open source utilities and projects that aim to make this decoupled architecture or running headless WordPress and Drupal sites easier.

    What brought me to that is, prior to Pantheon, a lot of my background was in the agency space. Specifically focusing on front end and front end develop. More and more I found myself interested in what was going on in the JavaScript ecosystem, and working on projects where using a CMS like WordPress or Drupal to feed data into the front end. But also found that there were a lot of solutions that were being invented over and over to solve those problems. So being able to focus on trying to make that easier for folks has been really exciting.

    [00:06:24] Nathan Wrigley: Thank you very much indeed. So you’re both coming from Pantheon and you mentioned there that you have a very keen focus on, well you mentioned two CMSs, which is curious actually. Obviously this is a WordPress podcast, but we’re not here to destroy the opposition if you like. But Drupal and WordPress, I think I’m right in saying that you don’t find too many hosting companies that lay claim to both of those. Is that a relic of the past of Pantheon, how it all began back in the day?

    [00:06:51] Steve Persch: It’s an intentional choice. We think that supporting both of those systems gives us more flexibility. It ends up fitting us better to our core audience. Pantheon started with digital agencies. Our four founders came from running web development agencies, that’s the background.

    And for a lot of the agencies and in the ecosystems we came from, we knew that it was normal for those sorts of agencies to have a preference between Drupal, WordPress or, you know, Ruby and Rails or any other of system. But often, the given client you’re working for might have both, for any number of historical reasons.

    So yes, the initiation of that was, uh, somewhat happenstance. Our customers figuring out like, this platform was first built for Drupal, I bet we could make it run WordPress. And then Pantheon as a company realizing like, yes, we should support WordPress. That’s something that I think was a bit inevitable.

    It’s good for us technologically and business wise to support more than one. And at the same time it’s good for us to not open it up as wide as, well, anything PHP. Some of our competitors take the other extreme of, hey, if you can make it run then you’re good. We think of ourselves as, we prefer the term, a website operations platform.

    And hosting is a feature of that. But don’t want to have a relationship with our customers that’s as simple as like, well, yeah, if you can make it run, that’s good. We’re only here to provide the server. We see ourselves as facilitating more growth of value of the websites, not just the question of can this run at all?

    [00:08:21] Brian Perry: Yeah, I think that, that same sort of concept also extends to the front end and JavaScript frameworks in that, there’s definitely a lot of excitement around Next.js. But we are looking to build a platform where other future frameworks can run on it. But also, yeah, we’re not necessarily trying to be like, run whatever crazy JavaScript project you want. We want to have some guardrails there.

    [00:08:44] Nathan Wrigley: I remember back in the day prior to stumbling across WordPress, which I did quite a long time ago now, I used to use Drupal exclusively actually, and I have a, have a memory of Pantheon cropping up, and at the time, really hadn’t heard of a hosting company that was binding itself to a CMS in that way.

    It was curious to me that Pantheon had laid claim to, okay, if you’re using a CMS, we’re somebody that you should look at. Prior to that, it was always, we’re just a hosting company. You know, we’ll host anything.

    [00:09:16] Steve Persch: I often go back to the first blog post that was done by, one of our co-founders, our four co-founders, when Pantheon started. I think the title of the blog post was Putting the Humans at the Top of the Stack. And it laid out, or at the time, but a decade plus ago, two common ways of running websites.

    One was just that hosting mode of a host providing some baseline technological capabilities, but the team buying the hosting is responsible for assembling the parts and making it all work. And yes, that’s an appropriate choice for some teams, but it’s not a great recipe for success for what we see as the broad plurality of professional web teams.

    The other extreme at the time, and it’s still present there, is the Squarespace, Wix, very templatized, cookie cutter way of building a site. Which again, is totally appropriate for certain people who need websites. But Pantheon, a decade ago and still now, wants to find a middle path that empowers the majority, or a plurality of professional web teams to make the best possible websites.

    And we see that, fulfilling that mission does require us to build CMS specific capabilities, and now front end framework specific capabilities, while not putting ourselves as narrow as only WordPress, or only Next.js.

    [00:10:35] Nathan Wrigley: Okay. That’s really interesting. Thank you for that. The subject at hand is really about how hosting has changed over the last decade, two decades, what have you. And it might be of interest to the listeners to the podcast if they pause for a moment and go and watch one of the videos. It was created by Steve, I believe, created the video.

    It’s called Decoupled Architectures, What Computer Assembles the website, and it’s a great watch. It’s. 10 minutes long, and it’ll give you a real insight into the things that we’re going to talk about. What Steve brings to bear is lots of papers and drawing, which we can’t do on this podcast, but they really do help solidify the problem. He’s got lots of nice diagrams of how things are working.

    But just to rewind the clock, let’s go back 20 years or so ago. It seems like an age almost at the birth of the internet almost. But if you had a website, whatever CMS it was. You would have to host it somewhere, and you would probably select a host and upload the files.

    They were probably at that point, just static HTML. I imagine CSS probably hadn’t even emerged at that point. And you just uploaded them. And you had a great idea of where that computer was. You had a slice, a share of that computer. It was yours. You could point to where it was on the map and so on and so forth.

    And that’s not how it’s done now. Or at least that’s not how everybody’s doing it. So I want us to run through a history of how that’s changed over time. Going right back from the beginnings when the internet began and you could build your own websites. Right up to how it’s done now. We can really be ponderous about this, we’ve got a whole episode ahead of us. So, whoever wants to begin that journey, you can flip flop and change, do tag team if you like, but that’s what I want to do. The history of how hosting has changed.

    [00:12:19] Steve Persch: Brian, if you don’t mind, I’ll start from flat HTML files, and enter us into the era of PHP. And then you can talk about CMSs. So one of my first experiences getting paid to maintain a website, a thing, I wasn’t even pondering as a career path. I was a theater major, and then I found myself working in the marketing department of a theater company. And they had a flat HTML website that did the job, was good enough for the early two thousands. A few hundred pages of flat HTML files, mostly it’s like if you want to buy tickets, call this phone number. Here’s the production that we’re producing, here’s the calendar.

    And one of the most annoying tasks, once I became the person getting paid to update the website was, add this menu link in the sidebar. And that sidebar appears on like a dozen pages. Okay, so I open up a dozen flat HTML files and then I notice, oh, this sub sidebar menu for the education department of the theater company. This menu isn’t even consistent on these 12 HTML files, because over however many years, copy paste errors happened. And that’s annoying, and creates a bad, confusing experience.

    But, I know enough to realize that I could put in some PHP tags, and save myself some time. That’s how I first started transitioning that question of, what computer assembles the website? How does this website really come together? The first answer of, it’s all flat HTML that I’ve got to hand code on my own machine to, what if I put a little bit more, just a little bit more intelligence in the server and told it to like PHP include education sub sidebar dot PHP.

    Then I don’t have to worry about copy pasting menu updates across 12 HTML files. That started to transition the question of what computer assembles the website, but the content management systems that were cropping up at the same time, WordPress, Drupal, others, provided a much more robust answer. But I can let Brian talk about that.

    [00:14:25] Nathan Wrigley: I’ll just interject at that point because the pain that you’ve just described was my pain. I remember exactly that. I mean, it wasn’t the 200 page website, but I remember the exact same thing. And then stumbling across the, oh, you can include something with PHP can you? That will take that whole burden, maybe the header or the footer or wherever it may be on the website.

    And I do remember finding that really quite startling, and thinking good grief. I’ve just saved myself literally hours of time, and it was fabulous. It was really, really an excellent moment. So, okay, so.

    [00:15:00] Brian Perry: It’s also a, it’s a gateway to the danger of creating your own CMS, I don’t know if anybody on this has done that?

    [00:15:07] Nathan Wrigley: Yes, that’s exactly what I did. We’ve laid the pathway then to, we’ve got PHP in there somehow now, and so now we’re moving towards CMSs. So I guess we’ll hand it to Brian to tell us what came next.

    [00:15:19] Brian Perry: Yeah, and Steve, feel free to jump in as the overall tour guide with any color commentary. But yeah so, many of us have rolled our own CMSs. But then projects like WordPress and Drupal come along and provide a consistent user experience to being able to manage your data. Have an associated front end.

    It’s the great situation where there’s a community of folks making that project better, rather than the CMS we built on our own. That is a situation where you have your CMS, that handles that data. But it is essentially a single lamp stack. And your CMS is responsible for assembling your website. So you can edit things in the admin. But at the end of the day, WordPress, for example, is what puts everything together, using its templates and providing the end page that the user interacts with.

    [00:16:15] Steve Persch: Another way I think about this progression is through the lens of the three really broad groups of people who make a website like this possible. Especially in those early PHP days, to make something like this work there’s someone probably with an IT sort of job title who’s setting up the server. There’s someone with like a web developer type of job title who’s making the Drupal or WordPress part work, and they may be working with designers as well. And then there are people managing the content.

    So in addition to what computer assembles the website, a more specific framing is where is the work of these three broad groups of people coming together? It’s coming together over and over and over and over again, to make a functioning website. And in the lamp stack era, it’s that PHP server, you know, be it shared hosting or a server in the closet. That is where the work of those three groups has to fit together.

    And for the decade or so that the lamp stack was dominant, there became pretty solidified best practices on how those three groups need to work together in order to do their jobs most effectively.

    [00:17:26] Nathan Wrigley: I feel that’s a really nice segregation of the different things that were going on. But also it makes the two bits that you are not involved with suddenly quite mysterious. If you’re the content editor, suddenly the IT bit, the hosting if you like, you’re no longer involved in that in any way. And, so that over time becomes a little bit more murky and what have you.

    But the advent of the CMS suddenly opened up a whole range of possibilities for people who really don’t have any technical, they don’t desire to be technical. They want to be consumed with the content. They want to log into something, type away, upload images, what have you, and press publish, and for it to be done.

    So I think that’s a really useful definition. Prior to that, you had to be fairly technical, at least technically enough to create the HTML and what have you, to then upload it to the server. And now we’ve got a kind of career path coming out of it, haven’t we? We’ve got the IT people, we’ve got the editor people, and various other different pieces of the puzzle.

    It feels like maybe that is where quite a few people will still be with WordPress. That is to say they’ve got a WordPress website, they’re paying a monthly fee to a hosting company. That hosting company is literally holding the files of the CMS, in our case, WordPress. Holding them on a particular box somewhere. The DNS is pointed correctly. It all works. That set up is still doable, but I guess the journey doesn’t end there. I suppose we’ve got quite a long way to go in this journey.

    [00:18:59] Steve Persch: Yeah, the journey does not end there. Actually it might, because it comes back around. There are other steps along the way. So, I see the next big event in this history as the release of the iPhone. Which for a while I wondered like, am I drawn to that as the key moment? Because that’s when I was coming into professional web development, around 2007. In the decade plus remove, I can see, no, that really was a big deal when we had to figure out how to make websites squish, and fit on different size devices. Phones, tablets, Android devices of every single size and resolution.

    That was a huge change. And it came about at the same time these native application ecosystems sprung up, and really, really raised the bar for how good of an experience you could have on these devices. So not only is this just a new form factor to make work at all. The quality bar jumps up very, very high. In retrospect, I can see like, oh, that set off a bit of a panic in the web development community. And different people reacted in different ways and, you look at the 2010s and think, oh yeah, people ran in a bunch of different directions trying to handle or deal with the existential question of, how does the web stay relevant when literally billions of dollars are pushing technology towards native applications.

    [00:20:33] Nathan Wrigley: I feel there’s some other pieces I might add into that as well, and that is, the invention of the iPhone, which then spawned so many other similar devices, some slightly larger, some competing operating systems. But the thing there was suddenly the internet went from something which was probably peripheral in your life.

    You would interact with it, maybe with email or something at work. You’d have to turn on a computer and sit in a chair. And the internet would be on that screen and then you’d walk away from it and you’ve forgotten about the internet. Suddenly you’re at a point where the internet is with you 24 7, should you wish. It’s there all the time. So it marks a moment where not only is it technically possible to do it, but it increases the importance in everybody’s lives. So, almost everything now, what are we now about 15 years later or something?

    Almost everything can have a web presence. You know, you were talking about buying tickets earlier. Well, what’s the best way to do that now? It’s the internet. How do you consume your radio? It’s the internet. Where does your entertainment come from? It’s the internet. There’s almost nothing, which the internet hasn’t touched, and I feel that that was the inflection point when it went in your back pocket and suddenly every company on earth had a window into everybody’s lives.

    [00:21:50] Brian Perry: It’s a blessing and a curse.

    [00:21:52] Nathan Wrigley: But also a convergence of the technology, you know. So cellular data was suddenly getting rolled out. Prior to that it was just mobile phones was as, as much as you could do. You could do voice chat and so on. But then mobile data came along and it all coincided at the same time. So I, yeah, Steve, I think that’s a really insight thing. The iPhone being this moment.

    [00:22:09] Steve Persch: So the iPhone, when it comes out, it suddenly becomes the most powerful computer in the whole stack. If you’re thinking about what can we make a website or a native application? What can I do with this device? A lot of people consciously or unconsciously realized if we push more responsibility to this last computer in the chain. From the developer’s computers. There are still servers involved.

    There are increasing number of computers in the cloud that are involved in getting the website to that iPhone. But the iPhone in many respects, the most powerful computer in the whole stack, and that leads to an architecture of, oh, let’s make that end device, be it a laptop, a high powered iPhone or a low powered budget Android phone. Let’s put all the responsibility there. Brian, I bet you could talk in greater detail about the upsides and the downsides of the single page application architecture that came about when a lot of the web development ecosystems said, oh, let’s put all the responsibility in the client, in the end device.

    [00:23:16] Brian Perry: Yeah, there’s definitely like a huge trade off to that in that the end result that we’re doing there, especially thinking about modern JavaScript frameworks, were essentially pushing more responsibility, more code, more JavaScript to that end device. So there’s more places where things could potentially go wrong.

    There’s more cases where rather than having just a HTML document that is passed from a device to device, it actually has responsible, responsibility for rendering the page and executing all of that code. And it’s even a situation where things as simple as being able to click the back button in your browser to go to the previous HTML document, that’s things that need to be handled within that client device.

    So it really does increase the complexity there. And then also related to what we’ve been talking about and thinking about, the three audiences that we talked about before. One thing that jumped out to me is that as we’re finding all of these, you know, the internet everywhere, and all of these, different devices that can be used for these different purposes. I think some of also what brings us to the headless architectures that we’re going to get to down the line, is in some ways, I think driven by the content editor. In that they still want to have one place where they can go and manage content that is going to show up in all of these different places.

    Whether it’s a client side page, a traditional website, things managed by PHP, and I think that also does start to lead us in the direction of how can we manage this content in one place and make that data available to all kinds of different consumers.

    [00:25:01] Nathan Wrigley: So we have the, we have the iPhone, and prior to that we have just regular servers. I guess we’ve now got to take a bit of a leap and stray into an area where maybe many of us really don’t know what we’re talking about, and I’ve very much include myself in this. What are the evolution of things that have happened subsequently since the iPhone?

    And what was the purpose of all of that? Were there things which were tried and failed? And I suppose we are slowly getting towards the present day, but if there’s been some interesting evolutions during that time which need to be mentioned to give context, please do.

    [00:25:35] Steve Persch: Absolutely, I think one dynamic that played out in the 2010s was the splintering of all these different disciplines. I said in that lamp stack era, there are these three broad groups, of IT and content editors and developers. And I was even lumping in designers with the developers there.

    There might be some designers who take offense to that, but you know, it’s a blurry line. I lump them together because at a very, a very zoom out level that that’s the group that’s responsible for controlling how the website looks. And the handoffs that happened between designer and developer have changed over the years.

    But in the 2010s, there’s just an incredible splintering of the amount of detailed knowledge necessary to make websites look good across all these different devices was so large it was just unreasonable to think that you can hire one human being to know how to even implement a good design across all of these devices.

    Who also knows how to, like, configure Advanced Custom Fields and WordPress. That’s not a terribly reasonable expectation, to think you can find one person who is excellent at both of those things. Some of those people do exist in the world, but for many team leaders putting together teams, they’re realizing, we’re going to be better off if we say like, Steve, you’re going to be the backend expert, and Brian, you’re going to be the front end expert. And, even though Brian has a whole lot of that backend expertise, for many teams, they just decided to make a hard divide in the people.

    And then subsequently, or the order was sometimes flipped, a hard divide in the technology. So for, you know, a lot of websites built in this era, there is a very hard divide between the content management system is over here, be it WordPress or Drupal or a natively headless system like Contentful or Sanity. That’s going to be managed by one group, and then this group of front end specialists will handle the front end presentation.

    That’s a hard cut to make. A question I’ve been asking for the last decade or so is, if we’re going to cut off WordPress’s head or Drupal’s head, where is the neck? That is an answer that is constantly moving. The next era, after single page applications, is static site generation. As people saw the, you know, that downside of single page applications, then it’s, oh, well what if we, what if we get some of the benefits of that old way of doing it where it was just flat files? Can we have flat files again, Brian.

    [00:28:06] Nathan Wrigley: Full circle.

    [00:28:07] Brian Perry: Exactly. That introduces a whole new set of challenges and trade offs. You know, it certainly does, things being completely static does provide a build asset that is immutable, and it’s easy to roll back. It’s something that can be cached on a CDN. But also it really changes, kind of going back to again, the editing experience. It really drastically changes that experience where someone who was used to editing a page in WordPress and clicking publish and then being able to see the page.

    Now you have a workflow where you make a change in your CMS or whatever the source of the data is, and then a build has to run to be able to have the end website updated. And how do you preview what that looks like before the build runs? Do you need a separate environment? That trade off definitely brings a lot of additional complexity potentially to the content editing experience now.

    [00:29:07] Nathan Wrigley: Yeah, I think it’s potentially very frustrating as well because although the technological benefits and probably things like SEO and all of those things. There probably are great benefits there. If you’re the content editor, there’s probably only annoyance that when you click publish nothing happens.

    We’ve got to wait for some, like you say, some build process to carry on. You’re adding in a great deal of incredible technological innovation, which speed things up and pushes things to different parts of the world, and I’m sure it’s something we can get into. But also from the content editing point of view, we’ve had this evolution toward being able to edit everything right away, and click publish and seeing it, to then suddenly yanking that carpet out from underneath them, which is yeah, kind of frustrating I guess.

    [00:29:55] Steve Persch: I called this the cliff of complexity. If you search on YouTube for that phrase, you can probably find a presentation that I did at Gatsby Conf. So Gatsby, as a front end framework, really became popular as that static site generator pattern was on the ascendance, because there are so many technological benefits to be had, but when you add in a handful of possibly extra requirements. Requirements like, well, the content editors really like to be able to press publish and see it immediately. That shoots you up this cliff where making that work in an architecture that is fundamentally static, is really cutting against the grain.

    Like it can be made to work, but is massively complex. And we think for a lot of teams like that complexity is just now worth it. The fundamental mode that WordPress has done for 20 years of like, you press publish and then you see it immediately. That is something that should not be compromised on for most teams.

    [00:30:56] Nathan Wrigley: We’re used to a trajectory where technology just gets better in every respect. So, not only does it get quicker, but the, you know, the UI is easier to use and there’s a complete expectation that if I could publish it yesterday, and click publish and it was published right away and I could examine and look for errors that I’d made.

    Well, we’re a year on from that. Why have you taken that capability away from me? We’re going backwards? Well, we’re kind of going sideways. We’re not going back because we’re just changing things. I think that would be a bitter pill to swallow. Hard to understand if you’re not technical.

    [00:31:30] Steve Persch: Yeah, absolutely. And I think that’s, that backwards moving or that sideways moving does happen in other places. That’s not something I think that’s unique to web development. I remember the first time I got a car that relied heavily on a touchscreen. I was like, no, I want a knob to turn up the volume on the radio. This is so much worse. But somebody thought, no touchscreens, that’s the future. No. A lot of cars are now backswinging. There’s some parts that we do need physical buttons and dials for. That is better.

    [00:32:01] Brian Perry: I was going to say, it’s funny that you bring up the car example because, my car actually has both, which is somewhat infuriating. There is a touchscreen that could do everything. And then on the console, all the knobs and buttons, they can do the exact same things. I feel like the JavaScript frameworks in trying to address the shift aggressively in the direction of static sites has had a period of time where it was the equivalent of my car that had both.

    So things started shifting back over to server side rendering. But a lot of the frameworks had, and still have, concepts of both at one time. So there are ways that you can say, I want to either build things statically by default, and after some period of time they’re invalidated and re rendered on the server. Or say that it’s this subset of pages that are pre-rendered statically. Maybe it’s my homepage, and my 100 most popular pages.

    And then other things are handled server side. That also does increase the complexity now. You have to know what things are static, what things are not. It’s kind of two different approaches. But yeah, it does feel a lot like my car that has essentially two completely redundant ways to interface with it.

    [00:33:19] Nathan Wrigley: I’m waiting for somebody to invent the car which has levers in it. So that you’ve got screens, dials, and levers. Then we’ll, we’ll truly have the car from across the entire century. So is that where we’re at now then? If we chart our history we spoke about HTML files, and then PHP coming along and then flattening things. Is that this history lesson ends, or is there more to say?

    [00:33:42] Steve Persch: The way I think about it, a phrase I often like to repeat to myself that came from a customer of ours, is that Pantheon needs to aim for state of the art, not bleeding edge. We see the state of the art for many web teams right now is one where you use a totally stable content management system like WordPress or Dupal for the content management systems.

    And because so many front end developers simply expect to be working in JavaScript centric tools for teams in that, in that pool. Yes, you should have the front end then controlled through JavaScript centric tools. But do so with server side rendering because the content editors expect to press publish and then immediately see the change. And that works well with server side rendering.

    So that’s, that’s a mode that we support in our front end sites product, the front end sites product does also support that static mode. Which is beneficial for a subset of teams out there. Like Pantheon’s own documentation site has been a totally static site for nearly a decade. I think as long as we’ve had a standalone docs site, it’s been static. And that works for that team where everything is all just in a Git repo. An edit to code can happen at the same time as an edit to the content markdown files. That works for that mode.

    But we see that, you know, the state of the art for some web teams, as that mix of a contact management system, and a server side rendered Node.js framework. I should also say, because we’re on a WordPress centric podcast here, if you are totally comfortable with WordPress, as is, you don’t need to jump on a new React framework or a new JavaScript framework, just because there are a lot of people on Twitter saying it’s great. If you can do your job without taking on the extra complexity, stick with what works.

    [00:35:28] Nathan Wrigley: Yeah, it’s a really good point. You mentioned there, now, I can’t remember the exact phrasing that you used, but you made a differentiation between bleeding edge and something else. Is that an approach that you take? Do you keep a watchful eye on what is happening at the extremes of technology.

    [00:35:44] Steve Persch: Oh absolutely, yes.

    [00:35:46] Nathan Wrigley: PhD thesis which are describing what the future might look like. But holding back just a little bit until it’s embedded and we figured out what all of this stuff is. That’s the approach?

    [00:35:56] Steve Persch: Absolutely. So it is not a coincidence that Pantheon as a company started a decade after Drupal came into being. It was starting as a Drupal centric company, and then adding WordPress a few years later. That’s not a coincidence. There needed to be a decade or so of figuring out, how do we make websites like this before Pantheon or any company like Pantheon could do what we did. Which is put guardrails around what our founders considered to be a best practice mode of developing and maintaining and improving a lamp stack site.

    Trying to impose those guardrails the same year that a system like WordPress or Drupal comes out, that wouldn’t make sense. Similarly, we didn’t really enter this front end framework ecosystem until about a decade in. I think almost exactly a decade after React, was released publicly is when we entered this space fully.

    We’ve been keeping an eye on it for a very long time. I’ve been at Pantheon for seven years and that was one of my very first questions, my first week, like, when are we going to get into the Node.js space? And the answer then was not yet. And then for a while, it was soon. And then the answer was like, okay, now.

    And now we can see, okay, the edge and one of the reasons I like to use that term bleeding edge is because that’s also the term for where the bleeding edge is now. The edge, as a synonym for the content delivery network. So companies like Cloudflare or Fastly that cache your website all over the world, have been adding more and more advanced capabilities beyond the simple caching that makes the website faster. That is very clearly where the bleeding edge or the cutting edge is now. We have a CDN baked in. We have ways of exploring that. However, put it all on the edge is not an acceptable answer yet for the broad plurality of professional web teams.

    [00:37:50] Nathan Wrigley: Why is that? What’s the thing which makes that untenable?

    [00:37:53] Steve Persch: The very short answer is because your database is still in one place. Even though the cloud abstracts so much like. There is a MySQL database or an abstraction thereof that lives physically in one place. Because we run on Google Cloud, that place for most sites on Pantheon is in Council Bluffs, Iowa.

    For a WordPress site that you know, may be making in some cases hundreds of MySQL queries to generate an HTML page, hopefully fewer than, than a few hundred, but in many cases, hundreds of queries. It’s best if the PHP process that’s making those queries is right next to, physically right next to that database.

    There are new companies popping up spreading your database all over the world at the edge. Okay, that sounds cool, but before, before we take some of the biggest websites in the world and say, oh yeah, your database will be everywhere. We need to see how that plays out with those who, who want to jump on the edge earlier. Because for the sites we serve and cater to they need to be planning in very long terms.

    We’re highly adopted in the edu space, and I, I’ve put together timelines on yardsticks to represent like the multi hundred year history of these universities that we’re working with. And asking like, on a multi a hundred year scale or a scale of decades, it doesn’t matter that much if you switch to the new thing, whatever the new thing is, this semester or next semester, or this year or next year? Let’s wait till we know that that next thing is solid before we jump on it.

    [00:39:23] Brian Perry: As the JavaScript guy, I got to say I want it now. But, aside from that, one thing that’s interesting from the front end perspective as well, thinking about running things on the edge. One of the challenges there is that right now, all of the different solutions for edge functions tend to use different variations of JavaScript runtime. So there’s really no consistency there. And I think that’s another thing that’s going to have to change before that gets real wide adoption, when there can be one consistent JavaScript runtime that is typically used for that solution.

    [00:39:54] Nathan Wrigley: You mentioned Steve, but Brian maybe can answer this as well, I don’t know. You mentioned that there are people who are endeavoring to break up the database and put it in all sorts of different parts of the world and what have you. So that’s one innovation which people are trying to achieve. I’m just curious about what the next 10 years will look like. What kind of fun, interesting projects have you guys been keeping your eye on, which the listeners may be interested in? Just to give some insight into what hosting a WordPress website might look like Well, in 2025, 2026, whatever it may be.

    [00:40:29] Brian Perry: My kind of, it’s partially my hope, but also where I’d like to think that things are going. With all of the constant changes in the JavaScript framework landscape, I think that more and more of the things that people like about that sort of developer experience is going to find its way just more generally into the platform and into browser standards.

    Again, like looking back in the rear view, jQuery is a good example of that, in that jQuery brought so many wonderful niceties for how you can interact with the DOM. And then over time, most of the things that jQuery can do are just in JavaScript now. So they’re part of the platform.

    So my hope is that the things that people like about React and Vue and et cetera, start to find their way into the general platform. Web components are one potential technology that might help there. A component based approach that can be used regardless of the framework.

    My hope is that in the next 10 years, a lot of the things that people turn to React or Vue or different frameworks for, are just a part of the platform, rather than having to find your cool JavaScript framework that was released three months ago,

    [00:41:47] Nathan Wrigley: Yeah. Nice. Thank you, Brian. Steve, anything to add to that?

    [00:41:51] Steve Persch: I’ll give a quick tech answer, then a longer, uh, philosophical sort of answer. So the quick tech answer is web assembly. I’ll be quick because I can’t speak to many of the details of web assembly, maybe Brian can? I see it as a layer that can abstract away many of the differences between the different computer languages that we’re all writing in. PHP, JavaScript, TypeScript, Rust. If web assembly is a common target that can be used to leverage software. You write in these different modes. Run it in the same place, be it at the edge, or I saw a demo recently that I think involved web assembly getting WordPress to fully run in your browser, like the WordPress running in web assembly in your browser. Okay, that, that looks cool.

    The thing I’m, I’m probably most excited about right now for where the overall web zeitgeist is going is, is that the web development ecosystem seems to be coming back to what WordPress has been saying for a long time, of decisions, not options as that philosophical pillar for the WordPress community.

    I find it very reassuring that these front end framework projects that for a decade or so, provided so many options and put so many decisions on the plate of individual web teams and said like, you figure out whether or not you want Redux or this other thing to pair with your React project, and good luck sorting out the hundreds or thousands of NPM dependencies that get installed.

    The frameworks that seem to be, that just are ascendant, right now, are the ones that are consolidating a lot of those options. Turning them into decisions that are made at the framework level, be it Next.js or Astro or Remix. The leaders of those projects seem to understand that there’s a desire in the community for, for those framework maintainers as experts to make a good quality decision that works for the broad majority of users of those frameworks. Be it Next or Astro or anything else. The users of Next.js are comfortable with an increasing number of decisions being first made in a centralized framework. WordPress has been doing that again for 20 years. Again, it’s fashionable.

    [00:44:11] Nathan Wrigley: Yeah, history I think in many respects is fairly cyclical. What goes around does seem to come around. Yeah, good observation. I’m curious at this point, we’ve reached the 50 minute mark, and I want to wrap it up. I know you’ve got things to do with your day. But is there anything that you had wished that we had talked about that we failed to?

    [00:44:31] Steve Persch: Brian, do you want to touch on Decoupled Kit?

    [00:44:34] Brian Perry: Yeah, I’d love to talk about that a little bit. The Decoupled Kit project is essentially what we’re thinking of as a kit, is essentially a backend starter project and a front end starter kit that are intended to work together as close to out of the box with as little configuration as possible. To try to simplify the process of setting up the headless or decoupled architecture sites.

    And also provide some common examples of types of integrations and common problems that need to be solved there. And the thing that I think is most interesting about some of what we’re doing there. Again, thinking about this being an open source project sponsored by Pantheon, is we’re trying to solve some of these problems in cases where it makes sense in a framework agnostic way.

    So, obviously starter projects for both Drupal and WordPress. And then within that we have a starter kit, we have multiple starter kits that are based on React. So we have a starter kit for Gatsby and WordPress, and a starter kit for Next.js and WordPress. So we’re trying to find cases where there are things that we can abstract out, which are just essentially like general utilities for sourcing data from WordPress. And not things that are really strictly tied to any one framework.

    So that if there is, you know, another framework in the future that we need to support, or gains popularity, it’s easy to make adjustments there and adapt to that. And I think in the headless CMS community, both in the Drupal world and the WordPress world. I think there’s a lot of opportunity for tools that are a little bit more framework agnostic, that can still serve popular projects like Next.js. But hopefully are things that the community can use as the JavaScript world evolves.

    I’ll just also throw out there that, would love to, as we continue to build things, any feedback on the project. The main repo is decoupled dash kit dash js, under the Pantheon Systems GitHub. Would love to hear what people run into, any features that they’d love to see us support in the future. Any feedback is welcome.

    [00:46:45] Nathan Wrigley: I will make sure to link to all of the bits and pieces that we’ve talked about in the show notes. So if you are listening to this and you want to follow up on what the guys have been mentioning, then head over to wptavern.com, search for the episode, and all of the links will be in the show notes. Just before I let you go and get on with your busy days. If somebody wants to reach out to you personally and connect, what are the best ways, what are the methods that you are willing to share publicly? Let’s go with Brian first.

    [00:47:16] Brian Perry: Sure. Yeah, I’m in a number of CMS and Pantheon community Slacks, usually as Brian Perry. That, that’s one decent way to get at me. And then also I am still on Twitter. That is my main connection to the web development social media world, currently. Bri Comedy, b r i comedy on Twitter.

    [00:47:38] Nathan Wrigley: Brian, thank you very much. And Steve.

    [00:47:40] Steve Persch: I am spending less time on Twitter these days, although I’m still there as at stevector. And LinkedIn is the social network that I’m opening most often these days, and I’m easy to find just by searching for Steve Persch.

    [00:47:55] Nathan Wrigley: Thank you very much. Brian Perry and Steve Persch really appreciate you coming onto the podcast today. Thank you very much indeed.

    [00:48:02] Steve Persch: Thank you, Nathan.

    [00:48:03] Brian Perry: Thank you.

    On the podcast today we have Steve Persch and Brian Perry. They’re both employed at Pantheon, an enterprise website operations platform, and they’re here to talk about the evolution of website hosting.

    Back when the internet started, hosting was a fairly straightforward enterprise. You created HTML files and uploaded them to a server. That was it. An HTML file was a page.

    Server-side technologies such as PHP came along and the picture became a little more complex. Web pages needed to be constructed on-the-fly. Databases were thrown into the mix and the complexity increased.

    Add in the different languages that you could write your code in, and the server configurations. The CMS that you choose also plays into this mix.

    Now we’ve got CDNs, headless, React, Gatsby, Node.js and much more. Is it even possible for the non-technical to have any understanding of where their website is?

    Steve and Brian talk about how they got into the hosting space and what’s changed over the years. We address what Pantheon is doing with WordPress and Drupal.

    We discuss how headless can be difficult for content teams, given that there’s a disconnect with hitting the publish button, and that content going live on the site.

    What’s certain is that there’s no end in sight in terms of the rate of innovation in the website hosting space. What’s popular today might not be several years from now, and so it’s a timely discussion of what Steve and Brain see as the best bets for the future.

    Useful links.

    Brian’s blog post about Decoupled Kit

    Steve’s video “Decoupled Architectures: What Computer Assembles the website”

    Contentful

    Sanity

    GatsbyConf

    Pantheon’s documentation site

    Cloudflare

    Fastly

    WebAssembly

    Next.js

    Astro

    Gatsby

    Brian’s Twitter

    Steve’s Twitter

  • #69 – Joost De Valk on What’s Happening After Yoast

    Transcription

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, what the founder of Yoast is working on now.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast, player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the podcast, I’m very keen to hear from you and hopefully get you or your idea featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today, we have Joost de Valk.

    If you’ve been in the WordPress space for any length of time, it’s likely that you’ve come across the Yoast SEO plugin. This was the brain child of the guests today, Joost. Same pronunciation, different spelling.

    We talk about how Joost found WordPress and quickly started working on his SEO plugin. How it rapidly grew and became his career.

    We discussed the WordPress landscape during this time, and whether it’s more difficult now to have the type of success that his plugin received, given that there are more players vying for our attention.

    The conversation then moves into why the plugin was recently sold to Newfold Digital. What were the guardrails that were put in place to ensure that the plugin continued and the employees felt safe?

    We then get into a conversation about Joost’s new role. He’s been tasked with reaching out to WordPress community members in order to see what projects or initiatives need more thought and support.

    This leads us into the topic of the current WordPress UI, and how Joost is hoping for a refresh at some point soon. For years, his plugin team wanted to create their own UI to take advantage of new technologies, but Joost always pushed back, preferring instead to adopt the style of the WordPress UI. Now that’s changed, and the open sourcing of the UI kit they’ve made is intended as a starting point for a discussion about the need for a more consistent admin experience for all WordPress users.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast. Where you’ll find all the other episodes as well.

    And so without further delay, I bring you Joost de Valk.

    I am joined on the podcast today by Joost de Valk. Hello Joost.

    [00:03:32] Joost de Valk: Hey, thank you for having me.

    [00:03:34] Nathan Wrigley: You are very, very welcome. It’s an absolute pleasure to have somebody of your stature in the WordPress community. You’ve been with WordPress for a really long time. Certainly whilst I’ve been using WordPress, I joined the party a little bit later than a lot of people. But your company and your name was already a really big deal.

    If anybody hasn’t heard of you, I’d appreciate it if just for a few minutes, you could just give us a little bit of your background story. Where you are, what companies you’ve worked for, how on earth did you get into WordPress and so on.

    [00:04:05] Joost de Valk: Okay, so that’s a lot to cover, but let me try. So, I am Joost. I’m Dutch. I live in the Netherlands with my lovely wife Marieke, who I think you’ve also had on your show, and our four kids.

    I started Yoast coming from a background of working in several different IT companies. I started university, basically failed at university because I wasn’t a very good student. Then started working in IT, in a web hosting company. And later on moved into an SEO company where I learned SEO consulting.

    When I started doing that, I had already been coding a bit. I’ve actually always been coding since I was 12. I built my first website when I was 12, which was in 1994, so you can do the math. I’d been working on that and I, I learned SEO at this company. Started blogging, and then also started building plugins for the blog platform that I chose, which happened to be WordPress. Building plugins to basically fix my own SEO needs. This was in 2005, 2006. So that’s relatively early days.

    I started contributing to WordPress Core at basically the same time. I’d been doing other open source software development. I was a part of the WebKit project, which is the core of Safari, and Chrome. Actually committer in that project before I joined the WordPress world.

    And I had two sites. I had one where I blogged about SEO, and one where I blogged about CSS. And my specialty at that time was CSS 3, which was at that point being created, and I was creating CSS 3 previews. So I was doing SEO for that, building my own plugins, just for myself. And I started releasing them and more people started using them. I started speaking at SEO conferences, and people started asking about these plugins.

    And one thing led to another. And some point in 2010 I decided to start working on my own. At that point thinking I would never hire anybody, but I would just be an SEO consultant, which is why I called the company after myself. Which in hindsight was a stupid idea, because whilst it is a very beautiful brand name, it is super annoying to hear your own name the whole day, because you can’t really not hear that.

    So, did that in 2010. Basically started SEO consulting. I was consulting for pretty large brands at that time, Facebook, eBay, the Guardian, companies like that. And, well I was still doing that plugin. Decided to bundle the several small plugins that I’d built into one larger WordPress SEO plugin, which later on became the Yoast SEO plugin.

    And then, at some point during 2011, I hit a million users with what was called WordPress SEO at the time. And Marieke said to me, you can’t keep doing this. You either have to start making money from this, or stop doing it, because this is nonsense. And she was, as always, right.

    And then started working on that. And she joined quite quickly. Had a couple of other colleagues who I’d hired to do part of the other work that I was doing at that point already. And we started building, and that went quite well for a very long time. So we sold in 2021, and at that point we had almost 150 employees, and a very well running business. So we’d been growing between 30 and 50% year over year for almost a decade. And yeah, it’s been a very interesting journey. And throughout that time I’ve been doing WordPress, because I love WordPress as a system, and I love the open source community.

    [00:08:05] Nathan Wrigley: I have a quick comment in here and I love how you described it, your successes. We did quite well. To get a million users in the space of, well, it sounds like under a year.

    [00:08:17] Joost de Valk: Well, no, it was, it was slightly more because it was, I had small plugins that people were already using, and then I bundled them into one. So I was basically combining all these user bases. But yeah, no, it, it did go very quickly. So a fairly limited amount of companies I’ve seen that do it quickly, although I have to say if you look at Elementor, similar and better actually.

    [00:08:39] Nathan Wrigley: When you look back at that time, do you consider that you entered WordPress at what might be described as halcyon days or something? Was there just something about it at that time, which was ripe for the picking? Because the growth from zero to a million, I mean very, very few plugins managed to jump that hurdle. And the fact that you did it, let’s say, relatively quickly, really quickly in fact, is pretty amazing. But I just wondered if the, if it was more wild west back then? If it was more possible because there was less competition, there was less rivals in the space. Do you have any insight into why it was so successful?

    [00:09:19] Joost de Valk: So part of it is that the people that were building WordPress sites at that time were, almost all of them developers, or at least website maintainers with a fairly good technical grasp. And they switched plugins fairly easily and often. I think that was a bit easier than it is now. Although that group is still there, but it’s just a smaller portion of the entire user base of WordPress now.

    So yeah, it was a bit different. It was a bit more pioneering I think, in a way. The thing is, we build these ginormous websites on WordPress now, right? So these enormously important websites as well to people. And you’re not going to play around with plugins on sites like that. So it’s on personal blogs that you can do that. And just a lot more people did have a personal blog at that time. It was probably the best days for the actual blogoshpere in comparison to what later happened with Twitter, et cetera.

    [00:10:19] Nathan Wrigley: We probably could spend the entire podcast talking about Yoast over the years, but we’re not going to do that, because we’ve decided to take a different route. But I, do want to ask, in terms of your journey since the day that you committed to having Yoast a plugin, right through to maybe today, maybe a year or two ago.

    Were you always in love with WordPress, the community and so on? I get the feeling that there might have been a few wrinkles along the way where the whole ecosystem was something that you wanted a little bit of a break from. I could be getting that wrong. If so, ignore the question.

    [00:10:53] Joost de Valk: I don’t think I’ve ever really wanted a break from WordPress itself. I think the community is a wonderful thing, but at the same time it’s very brittle. People come and go, and that’s fine, right? But we, I feel, have failed in the last few years especially to, well to show our excitement for it to each other.

    I think part of that is Covid, because there weren’t as many WordCamps and other things while we did that. Part of that is also, we’re all growing up and all these companies are becoming bigger and, well the demands on those companies are getting bigger. But it’s also like we’re getting more professional, but with that maybe also a bit more dull

    [00:11:37] Nathan Wrigley: So you’re still committed to WordPress. Is that the case? Are you going to be with WordPress do you imagine 3 or 4, 5, 10 years from now? You’ll still be coming on podcasts like this and talking about WordPress, albeit in a different role?

    [00:11:51] Joost de Valk: I absolutely hope so, yeah. If I wasn’t thinking that, I wouldn’t have taken on this new role that I took on at Newfold.

    [00:11:58] Nathan Wrigley: Yeah, let’s talk about that. But before we get onto that, I would imagine there’s a subset of users who know that Yoast as a plugin exists, but they may not know about the ownership and the structure and how it’s all run and what have you. Just run us through that little piece. A little while ago it was announced that you had sold to Newfold Digital. What was the reasoning behind that? So that could be maybe there were personal reasons behind that. Maybe it was just something that you wanted to get away from and give yourself a bit of head space, try something new. What was going on in the run up to that, and how did it all go?

    [00:12:32] Joost de Valk: So, well running a company’s hard. And as a company becomes bigger, it becomes harder. And during Covid, Marieke and I decided it’s time. It’s time to, to sell it and to look at, like, hey, what else do we want to do? And we were talking about that to our other partners. I think we all felt the same at that point.

    And so we went into a process. We actually engaged a banker who helped us sell the company. And we ended up with Newfold Digital, which is not really a household name, but it’s the parent company to companies like Bluehost, Hostgator, domain.com, and multiple dozens of other brands.

    They put in a good offer, but they also had a very good story about why they wanted to buy Yoast, and what they would do with it. And that really was very interesting to us. And then, they ended up after acquiring us, quite quickly after that, they also acquired Yith. A WooCommerce plugin shop, also from Europe. It’s been good. It’s a very nice group of people.

    [00:13:41] Nathan Wrigley: With the transition there, when you went out and as you said, you got some third party in, who obviously had your best interest, but also presumably could be somewhat dispassionate as well. Did you have any sort of guardrails? Because you described that you’d grown from, well, you solo up to 150 employees, and just before we hit record, you were mentioning that in some cases, some of your employees have been there for as much as a decade. You know, there’s a real long heritage of people working there. So presumably a lot of these people, you’re very close to them. Friends you might say.

    [00:14:15] Joost de Valk: Absolutely, yes.

    [00:14:17] Nathan Wrigley: I presume part of that process was protecting them, knowing that when you stepped away and released the reins, that whoever took over the reins was going to behave in a way that you would have behaved. Did you get into that? Did you struggle with that? Was there any, any pieces that you needed to in place?

    [00:14:36] Joost de Valk: It’s definitely a part of why you’re thinking very long and hard about who you’re selling your company to. To some extent, we don’t need to do all the defense because there’s Dutch law that will actually prevent them from just firing people. If I lived in an at will firing world, I would probably think about this even more specifically.

    But, honestly it was never a question, they wanted the people. And they wanted everyone to come board and to stay on. And actually in the first year after we sold to Newfold, nobody left. Or in the first six months, I should probably say, I don’t know whether it’s entirely true for the first year. Nobody left for a long time.

    No, I think actually treating your employees well is super important. To be fair, that’s always been one of the things that Marieke has run at our company. So for a long time I was the CEO, then she took over from me. So she was the CEO for the last three years before we sold. Well, she did a tremendous job at making well, creating that culture and making it even better.

    We do indeed have quite a few people that work here for, well, five years or longer. And a couple of them, two people now who are at a decade and one is closing in, yeah.

    [00:15:51] Nathan Wrigley: You mentioned, I can’t remember whether it was in the conversation we’ve just had or whether I read it in some show notes. But Newfeld Digital, the company that you ultimately sold for. This for now at least, this is the direction of travel for you. What’s the role that you’ve taken on there and what are the sort of key points that you are trying to achieve? You also mentioned that it’s not a household name. I suspect there’s some will to change that might be part of your role.

    [00:16:15] Joost de Valk: Not necessarily, I mean, Newford is a corporate brand mostly aimed at other things than, it’s not like we need everyone to know Newford. But I do think it’s, well the combination of Bluehost and Yith and Yoast, and quite a few other things under our umbrella make us quite a big player in the WordPress world. We are, I think, the biggest or the second biggest WordPress host out there. Maybe GoDaddy’s bigger, I honestly don’t know.

    So my role specifically for the foreseeable future, is to look at hey, what’s happening in the WordPress world? How can Newfold help WordPress, and what can we do in the WordPress world that would benefit both Newfold and the WordPress world?

    And how can we use our knowledge of WordPress internally a bit better as well. It’s funny how this works at large hosts and these are, Newfold is not unique in that I’ve found. I’ve been talking to other people in the hosting space a lot in the last few months. A lot of these hosting companies, only in the last few years have started realizing that they’re actually WordPress companies.

    There’s a bit of a catch up to do there. Well, it’s one of the things that I want to focus on is like, how can we see that these large hosts who make a lot of money on WordPress and who together create quite a big economy, that they contribute back to WordPress as well? And what can we do about that?

    [00:17:40] Nathan Wrigley: So if I’m right, your role is head of WordPress strategy for Newfold Digital? That is a part of it. It’s just trying to figure out where WordPress fits in the overall structure, the products that you’ve got, the direction that you’re going to take, the events that you’re going to show up to, and all of that?

    [00:17:57] Joost de Valk: Yeah, absolutely. And it is honestly, it’s sort of a perfect role because I have no one reporting to me, and yet I get to talk about these things, which I love.

    [00:18:08] Nathan Wrigley: What have been some of the things that you have been mulling over that at Newfold you think you might like to get your hands dirty on?

    [00:18:15] Joost de Valk: Well, I think it actually ties into one of the other things you wanted to talk about, which is the WordPress Admin UI. So we did a new settings UI for Yoast, and as I was looking at it and we were building that. I was talking to my colleagues at Newfold responsible for the Bluehost interface and for Yith, and we were like, hey, can’t we just use this across the company?

    So it’s stuff like that where we, we help each other with our knowledge of WordPress. And we also let people who are good at one specific thing inside WordPress do that. But it’s also like, okay, we have a couple of different teams of WordPress Core contributors within Newfold. How can we effectively use those?

    So yeah, there’s a lot of different angles to it. There’s how do we make more money from WordPress? What direction does WordPress need to go, and how can we help that? How do we make WordPress better usable for our customers so that we actually maintain our customers better? There’s a lot of different things to do.

    [00:19:17] Nathan Wrigley: You’ve been really keen publishing statistics over the years about WordPress adoption and WordPress usage and all of those kind of things. So it really does seem like the perfect role for you. You’re very interested in the bigger picture of WordPress and how widely it’s adopted and whether the numbers are going up or going down and publishing data about all that. Yeah, it’s fascinating.

    [00:19:35] Joost de Valk: It is. WordPress is just a perfect project for a large number of the websites out there. And honestly, I think that we, that we don’t always do ourselves a good service as WordPress on marketing what we can do. And we’ve also, I think, underinvested a little in some parts of WordPress, in terms of performance and in terms of onboarding, that we should probably invest a bit more in.

    [00:20:02] Nathan Wrigley: Yeah, that’s an interesting point. Just as a segue, the whole performance thing, not the onboarding piece, but the performance bit in particular. I feel that’s, that’s really been kickstarted over the last 12 months. There seems to be a lot of work going into performance and a lot of chatter about it.

    Whether everything should be bundled into one performance plugin or whether it should be split out and become different canonical plugins, if you like. So I think you’re right. I think it’s quite interesting that some of the things that you’ve just mentioned do seem to be getting some attention, and performance is just one that springs to mind.

    [00:20:36] Joost de Valk: Things like performance on an individual site level, they’re important, but if you are the host that is hosting literally millions of WordPress sites. It is just literally also cost to your bottom line.

    [00:20:49] Nathan Wrigley: Yeah, I hadn’t really thought about it from that perspective. But if you can shave, I don’t know, 5% of CPU cycles out of the whole hosting platform, that’s quite a large amount of money that you’ve saved.

    [00:20:59] Joost de Valk: Yeah, and we did a lot more than that in recent releases. So it’s been in the double digits. And that’s absolutely a good thing for, well, not just for our bottom line, but for nature and for electricity usage. I mean, there’s tons of reasons to want to do better at that. And I think there’s still a lot more that we could do.

    [00:21:21] Nathan Wrigley: I think it does seem genuinely to be a perfect role given, well, given that I don’t know you particularly well, but from all of the things that I’ve read over the years, it seems like this is kind of like a match made in heaven.

    [00:21:32] Joost de Valk: Yeah, and it is actually a very nice team. So it’s, it is very nice to be able to work with these people, and look at like, hey, what can we do here? And yeah, I hope to be able to make an impact.

    [00:21:42] Nathan Wrigley: Let’s talk about the UI, because over the years, if you’ve been using WordPress for all these years, you must have logged into WordPress, oh, I daren’t even count. But it’s probably multiple tens of thousands of times. And each time you’ve logged in, you’ve stared at the same UI. And certainly over the last decade, that UI has been exactly the same.

    It basically has looked the same since I started WordPress, with tiny, teeny modifications to things like the color blue. There’s a slight variation in the color blue that’s being used now than previously. But broadly speaking, it’s exactly the same.

    You guys, and we’re going to use Yoast as an example, but it really, it could be any company. You guys took it into your own hands to say, enough. We think that the UI, if we stick with WordPress standard UI, it doesn’t really fit what we’re doing. Technology’s moved on. We’ve got more things available to us. Certainly the way things look in WordPress is beginning to be a little bit tired.

    Tell me about that journey. And are you hoping that your free UI kit, that you’ve open sourced is going to be taken on? Maybe it’s a cue for the team over at .org to have a look at this and adopt this across WordPress, dare I say?

    [00:22:53] Joost de Valk: I honestly doubt that’ll happen. Yeah, no, I doubt that. Not because they are against using something that we’ve built, but because what we build is quite opinionated and uses stuff that they might not be willing to use, like Tailwind.

    It definitely needs a change. It’s been a tired look for, well, almost a decade as well now. We’ve had experiments. We’ve not really moved on that. Gutenberg itself has changed in what it looks like a couple of times over its development, and now we’re basically stuck with three different types of designs, even within the WordPress admin.

    [00:23:29] Nathan Wrigley: Yeah, tell us what you mean by that because I’m not sure everybody will pick up the nuance of that.

    [00:23:33] Joost de Valk: Well, if you look at the site health page, it uses different styling from say, add a post. And then go into a post and you edit it in Gutenberg, then that looks entirely different as well. And, I just think that’s weird. I think it’s weird that we have different types of buttons. I think it’s weird that we basically teach a user two or three different UIs. And if you use the customizer with it, then even more. So you’re basically teaching people new user experiences all the time, and that makes it hard to use.

    And then because there is no real design system for WordPress anymore, that you can use to build your plugin’s admin pages, everyone starts building their own and all of them start looking differently. And that means that if you have five plugins, you have five different admin pages. And I just don’t think that that’s a good experience.

    [00:24:35] Nathan Wrigley: Yeah, I guess if you are a user of WordPress, a frequent user of WordPress, and you’ve got let’s say, the one site that you are maintaining all five sites or whatever it may be. Because you’re in there all the time, that dissonance doesn’t really happen for you as much, does it? You know, you’re just familiar with it.

    Okay. If I go in here, I’m going to expect that the menu’s going to change. The whole color palette and everything. The buttons will look different, but okay, that’s how it is. But if WordPress continues to grow, and it wants to get into the late forties and early 50%, which is, I guess, a target which is within reach. That isn’t really going to fly anymore, is it?

    Because if you go to any SaaS app, let’s say for example, I don’t know, let’s say you go over to Google and you want to interact with Google Docs, it would be really weird if the UI for Docs was different from spreadsheets. And, I don’t know, let’s say that you are using Notion or Evernote or something like that. If when you went into some portion of it, it was just different.

    You just fully expect everything to look and feel the same. And in our own experience of WordPress, we just forgive that, don’t we? We just, oh, okay, that plugin author has done this. But if you are looking to compete against the rising stars, Wix, Squarespace, Shopify, all these other things, that really starts to matter.

    It’s a bit like death by a thousand teeny, tiny little paper cuts. Those things stick in the head of the end user. That just seems a bit unprofessional. Not sure about this WordPress thing. Do you think I’ve hit the target there?

    [00:26:08] Joost de Valk: Yeah, no, absolutely. I think that is our problem. I think it actually ties into the other thing I mentioned, the onboarding. It’s actually pretty hard to start using WordPress. So you are thrown into a dashboard and then the first thing you’re greeted with is WordPress meetups. And as much as I love WordPress meetups, if you are just on that page for the first time, why are those in my screen?

    And, well there’s a hundred things like that where I think that we, we could and probably should do better. And the first thing would be, in my opinion, a design system that we all agree on. And I think that is actually an achievable goal. I spoke a bit, before and after I published my post, to a couple of people from the design team, Joan and Mathias, and they also seemed to want something like that.

    We seem to disagree a bit on how far, in how far that actually already exists. Because there is a somewhat of a component system within Gutenberg. I just think that as long as I search for WordPress design system and don’t get a post or page from WordPress.org, that actually explains the design system in simple to use terms for every plugin developer out there, it doesn’t exist.

    That means that we have to build it. We have to market it. We have to think about how it’s going to be used and then write good docs for that. That’s quite a bit of work, but it’s not unconceivable that we do that. There’s a lot of people in the WordPress world who want to make that happen. We’re just not prioritizing it at the moment. And I think we’re doing ourselves a disservice by not doing that.

    [00:27:45] Nathan Wrigley: I am going to link in the show notes to an article that you put out recently where you express a lot of these thoughts. And in it you make the point that it was a really difficult decision over at Yoast. Sorry to keep going back to Yoast.

    [00:27:59] Joost de Valk: No, it’s not a problem. It was a very difficult decision. We’ve been literally been talking about this for five, six years, and my UX team at Yoast had been wanting to do a redesign for a long time, and I basically stopped them all the time because I was like, I want to stay in line with the WordPress admin.

    And over time we started moving away from it more and more because we needed stuff that simply wasn’t there. And then at some point you have to admit like, okay, I’m wrong. This is not going to happen and we need to build our own. It was sort of like a bittersweet decision. And I’m happy to add that people are responding well to the library that we built and that, that we open sourced.

    Because I want to spare others to work. Because it’s stupid. It’s stupid that as a plugin developer, I have to spend time thinking about what do my buttons look like? What do my toggles look like? They should just be the same for everyone.

    [00:29:03] Nathan Wrigley: I can completely sympathize with that, in the sense that you’ve spent years basically saying, no, to your design team. We’re just going to stick with this. But eventually, I guess there’s too much water has gone under that bridge that really you’re stifling your own company’s enterprise.

    [00:29:20] Joost de Valk: Literally, I mean, people moved to others plugins because they thought it looked better. Which I think is a stupid reason to switch SEO plugins. But who am I? But it was literally happening, and I, at some point you go like, okay, I really need to do better at this. And to be fair, the new settings you are that we ended up building, I think our UX team did an amazing job on, and makes the plugin a lot easier to use.

    [00:29:49] Nathan Wrigley: I will link to the design library, which has been open sourced again in the show notes, but it’s a really amazing endeavor. If you are a plugin developer or, you know, you have aspirations to be, it’s definitely well worth checking out because looks like Yoast have really gone to town. It’s soup to nuts. Almost every component or element that you could possibly imagine putting inside of a WordPress UI, is there, you know. Progress bars, radio buttons. Every single thing is there with loads of instructions on how to implement it.

    I guess if the endeavor was to begin that conversation, then already, I think it’s been a success. If the endeavor of this blog post and the, the new UI that you’ve bring into existence. If the endeavor there was to start a conversation about this, then yeah, I think you’ve done that.

    [00:30:39] Joost de Valk: At this point we’ve invested so much time that I don’t see us switching to something else anytime soon. But that also sort of saddens. That’s why I wrote the post on my personal blog. I’m like, this is not necessarily the decision I would’ve wanted to make. But yeah, you are sort of forced into it. At that point it’s better if we build something and we open source it, and then maybe a lot of others can use it as well. And maybe we can actually get to an interface where we all sort of look alike.

    [00:31:08] Nathan Wrigley: Have you been in the role at Newfold long enough to have interfaced with customers to know that this is a, a thing which is stifling WordPress growth. The fact that it does look out of date. The fact that it’s a jumble of different colors and patterns and design libraries being in used in different plugins. Does this turn people off in the real world?

    [00:31:28] Joost de Valk: I’m a hundred percent sure. You test with these things, of course, and you see the data on how many people start. Register with a host. They get a hosting package. They get a WordPress site, and how many then get to a published site? Not everyone gets to a published site, and that I think will never happen, but well the more that do, the more that will basically remain customers. So for a host, that’s an important metric.

    And people just get stuck. And then when you look at where they get stuck, they get stuck at picking a theme. And then when they have a theme, they get stuck at making it look good, especially making it look like the demo.

    And then they get stuck at building pages. They get stuck at several phases. And there’s quite a few of those phases that you have to get through before you get to a website that you’re happy with. So we’re trying to make that simpler, and I think we’re actually doing very cool work on that at Bluehost and Newfold in general. But some of that should also happen in Core.

    [00:32:29] Nathan Wrigley: Yeah, it’s interesting. If you are Squarespace or Wix or whoever it may be, I guess the person who’s in charge of the way that the platform looks, just makes the decision and it’s done and everybody then toes the line and does that thing. Okay, we’re going to make it look different. We’re going to modify it. 2023, we’re going to give our entire enterprise a new look and feel. Let’s get on with it.

    Of course, in WordPress, given the nature of the way that the software is developed, that’s really hard. And getting people to have a consensus on this, like you said, you’d had several chats with a few people who may be able to push the needle a little bit there, and there’s not always complete agreement.

    It will be difficult, but my personal feeling is that it needs to be quite high on the list of things happening. But given that Gutenberg, we’re about to enter phase three of Gutenberg. Given that Gutenberg is consuming so much time and resources of developers, I do wonder whether this interface will get much of a makeover in the next, I don’t know, next year or so.

    [00:33:32] Joost de Valk: I wondered that too. I don’t have an answer because I don’t know, but it is a conversation that I’m going to have, be having with people. And I do actually think that it might, it might field counterintuitive, but I actually think that building that design system first might actually speed up the other work.

    [00:33:51] Nathan Wrigley: Yeah, well it certainly gives you a benchmark of what can be achieved. Yeah, it’d be interesting in your new role, whether or not you can corral some people into pushing that forward.

    Yoast, we’re reaching the 40 minute mark. I think that’s about where I wanted to get to. If there’s anything that you think I missed, please let me know.

    [00:34:10] Joost de Valk: No, there’s always more to talk about, it’s WordPress.

    [00:34:13] Nathan Wrigley: If that’s the case and we’ve covered everything, I’ll just ask you to let us know where people can find you, given that you’re in a transitionary period. Where’s the best place for people to discover you from now on?

    [00:34:25] Joost de Valk: That’s joost.blog, j o o s t.blog. So my first name, not the company name. And Twitter, j d e v a l k, J de Volk is probably the best place. And if people have questions or want to just chat, I’m on the WordPress Slack as well. So feel free to DM me there.

    [00:34:44] Nathan Wrigley: Thank you very much, Joost for chatting to us on the podcast today. I really appreciate it.

    [00:34:48] Joost de Valk: Again, thank you for having me, it was a pleasure.

    On the podcast today we have Joost De Valk.

    If you’ve been in the WordPress space for any length of time, it’s likely that you’ve come across the Yoast SEO plugin. This was the brainchild of the guest today, Joost, same pronunciation, different spelling.

    We talk about how Joost found WordPress and quickly started working on his SEO plugin. How it rapidly grew and became his career.

    We discuss the WordPress landscape during this time and whether it’s more difficult now to have the type of success that his plugin received, given that there are more players vying for our attention.

    The conversation then moves into why the plugin was recently sold to Newfold Digital. What were the guardrails that were put in place to ensure that the plugin continued and the employees felt safe?

    We then get into a conversation about Joost’s new role. He’s been tasked with reaching out to WordPress community members in order to see what projects or initiatives need more thought and support.

    This leads us into the topic of the current WordPress UI, and how Joost is hoping for a refresh at some point soon. For years his plugin team wanted to create their own UI to take advantage of new technologies, but Joost always pushed back, preferring instead to adopt the style of the WordPress UI. Now that’s changed, and the open sourcing of the UI kit they’ve made is intended as a starting point for a discussion about the need for a more consistent admin experience for all WordPress users.

    Useful links.

    Yoast SEO plugin

    Elementor

    Newfold Digital

    Bluehost

    HostGator

    domain.com

    Yith

    Tailwind CSS

    Joost’s post about the WordPress Admin UI

    Joost’s Twitter

  • #68 – Chris Reynolds on Why To Use Composer With WordPress

    Transcript

    ​[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, why you might like to add Composer into your WordPress website workflow.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you or your idea featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today we have Chris Reynolds. Chris has been working with WordPress for over 15 years. He’s freelanced, worked with Event Espresso, WebDevStudios, Human Made, and is now at Pantheon as a CMS ecosystem engineer and WordPress technical lead.

    He’s spoken at WordCamps and at OpenWest about all aspects of WordPress.

    I suspect that many of the people listening to this podcast are not using Composer in their WordPress workflow, and to Chris this is something that you should think about implementing, and he’s here to explain why.

    Chris starts off by talking about the kinds of projects that he’s worked on, and how we found WordPress.

    We then get into the weeds of what Composer is and the benefits that it brings. It’s essentially a package management system, and makes it easy to set dependencies for your project and manage them within Composer.

    Why would you want to do that though? If you’re just building brochure websites, then perhaps you’ve don’t. But if your project is more complex then this might save you a lot of time.

    Chris describes scenarios in which she thinks Composer is a good fit; if you want to add in specific packages and how those packages are managed and updated.

    He explains how you can install composer depending on the OS that you’re working with, and how it structures the files and directories that are created.

    Towards the end of the podcast, we talk about how composer can be useful for teams, and Chris’s use of Composer to keep everyone clear on how the project is structured.

    If you’ve thought about using a package management system, such as composer, this episode is for you.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

    And so without further delay, I bring you Chris Reynolds.

    I am joined on the podcast today by Chris Reynolds. Hello, Chris.

    [00:03:40] Chris Reynolds: Hi. How’s it going?

    [00:03:41] Nathan Wrigley: Very well, thank you. Chris is on the podcast today to talk to us about something that I confess I know very little about. I’m going to guess that if you’re a typical WordPress user, you too may be learning a few new things today. It’s all going to be about Composer. Before we get into Composer, what it is, how it works, and all of that, wouldn’t mind Chris if you just orientate our listeners. Give us a little bit of insight into you and your WordPress journey. The companies that you’ve worked at. The things that you’ve been involved in and so on. So over to you, Chris, give us your intro.

    [00:04:14] Chris Reynolds: Sure. I came across WordPress right around the time that my son was born, which was 2005. The internet was a very different place back then, wasn’t it? At the time I was looking for something to like share pictures with family and stuff, make a website.

    Back then I had what was then referred to as a weblog. It was before that was shortened to blogs, and it was literally a log of things that I did on my website, update changes. And that was all hard coded html. So when I was trying to think of something to share pictures, didn’t want to do it hard coded. I did do that for a little while and then I decided this was not the thing I wanted to be doing.

    So there used to be a website called Hot Scripts. There I found a blogging platform called S Blog, and I was using that for a really long time. But as happens in open source, and actually honestly, as part of what happened in the WordPress history, the original maintainer and author disappeared for a little bit, and it wasn’t getting updates and I think there were some security things at some point. And I started looking for something else. Had some friends that were talking about WordPress, so I was like, I’ll try this thing out, and basically haven’t looked back.

    At a certain point after my son was born, I decided that I wanted to quit my regular job, which at the time was doing tech support for grocery stores, and become a freelance web designer. And I did that for a few years. Was familiar with all of those Elance and I don’t even remember all, like freelancer.net or something. Like all those really old sites to get freelance work. And I worked for a time for a company that’s actually local, as an outsource, freelance web designer.

    There, I believe owner, ran off with all their money or something, and the company closed down. That was a fun story. And then I met the folks from Event Espresso, which is a event management plugin. I met them at WordCamp Salt Lake City because they’re local, and Salt Lake City is where I live.

    And I started working with them initially just doing tech support for them, and then I got into a little bit of development and then I got into a little bit of project management and development. And then I was at a WordCamp, I was speaking. And Pluralsight, which is an online training platform saw me speak and asked me if I wanted to do that sort of thing for them as a, as an author of WordPress related training courses.

    So I started doing that while I was working at Event Espresso, and then eventually I quit to focus on that. And did that for about a year or so. And then, I started getting into agency world. So I worked at WebDevStudios for a couple years. And then I went to Human Made. I was there for almost five years. And now I’m working at Pantheon as a software engineer focusing on WordPress ecosystem things.

    So I’ve been involved in very small projects. I’ve been involved in very large projects. I’ve been involved in training. For a while I did some work with the docs team for WordPress documentation. I went to the community summit in San Francisco way back in the day. I’ve spoken at lots of local WordCamps and OpenWest which is also held locally. And yeah, I’ve been around for a little while.

    [00:07:12] Nathan Wrigley: Yeah, you really have. That’s an amazingly long history, and going back with WordPress to 2005, you really were right at the forefront. It was just the very beginnings at that point.

    [00:07:22] Chris Reynolds: It had been around for a while. If you look at the screenshots of the admin, I wasn’t the very first iteration, but I think I was maybe the second iteration.

    [00:07:31] Nathan Wrigley: Who knew back in 2005 that it would become such an important part of the ecosystem of the web in general. We’re at the point now where 40 plus percent, I still never quite know what that number means, but it’s a big number and WordPress is an important part of it.

    You say that you’re a Pantheon at the moment. Just give us a little bit of insight into Pantheon because I confess, I don’t know a great deal about it. But in my mind I’m thinking managed WordPress hosting and also managed CMS hosting possibly some other variants as well. Just tell us a little bit about what Pantheons skin in the game is with WordPress.

    [00:08:09] Chris Reynolds: You’re not wrong. We like to call ourselves a web ops platform and we also have kind of coined that web ops phrase, which means that outside of, speaking about Pantheon, it almost doesn’t exist. What web ops is, it’s website operations, right? It’s the things that make your website go.

    And what that means practically is that the way that the platform has been built is from the ground up to make sure that teams are able to develop on their websites in a way that is easy to deploy, that is safe, and that is secure. And there’s all sorts of platform centric things that are part of the workflow.

    Pantheon was one of the first, when I was working at WebDev, was the first exposure that I really had to Pantheon. And it was the first platform that I had used that had integrated Git. So you didn’t have to like, put your stuff on GitHub and then figure out a way to point that deploys to a server somewhere.

    It was already built in. And they had been doing that from the very beginning. It also had as part of that there is a dev test live workflow where there’s separate environments. And this isn’t uncommon today, but it was one of the first places where you could do that and had it built in.

    And then the real sort key feature that I enjoyed as a developer and still enjoy as an employee honestly is the concept of multi devs. Where if you have a branch that you are doing work on and you want to see what that branch would look like. Typically in my agency days, the way that you would handle this is by merging that into dev, and dev becomes really messy, dirty because it’s got lots of basically untested code, or code that was maybe tested and then rolled back or whatever.

    Dev is always nasty, a nasty place to be, and you never deploy from dev. That was always the rule when I was working in agency stuff. Multi devs solve that problem by spinning up an entirely new environment for a branch. So you can create a multi dev off of whatever branch, and then you can test it there, and then you can merge that into dev or whatever.

    Your dev branch is clean because it’s not, you’re not getting all this test code, experimental code that’s getting merged in, and then maybe you’re making some changes or maybe you’re fixing some stuff, undo some stuff that was from an old merge.

    That way you can keep your branches clean. And that’s a really cool thing that Pantheon does that I’ve often have wished for when I was working elsewhere, or working on sites that were not hosted on Pantheon. So that’s one of the things that Pantheon does.

    We were talking before we started recording that Pantheon was built by four or five Drupal dudes. So it’s been a Drupal shop for a very long time. And then maybe about 10 or so years ago, when I became aware of them they started doing WordPress sites. Still built on the same infrastructure that they had built with all the same live workflows, multi dev, all that sort of stuff.

    And now we’re getting into a point where we’re really trying to build out and optimize for WordPress and find where our gaps are in terms of how the platform has been built and what WordPress specifically needs. And that’s essentially what my team is involved in.

    [00:11:10] Nathan Wrigley: Nice. Yeah, that’s a real interesting set of things that you talk about there. I didn’t actually know prior to our conversation we had before we hit record, I didn’t know that it had all begun on the Drupal side of things, but obviously as WordPress has been in the ascendancy for the last 10 years, it does feel like an important pivot for any company really to make, is to give an experience to WordPress users which is optimized for them.

    So, yeah, I’ll make sure to link in the show notes to anything that we talk about. So if you’re listening to this, don’t worry too much, you can go to the WP Tavern website and search for this episode and find all the links there.

    Now I’m going to include quite a few links to what we’re about to talk about. This is the main thrust of the podcast. It’s something called Composer. Now, when Chris reached out to me, he mentioned that he wanted to talk about Composer, and I’ll be really honest, it’s not something that I’m familiar with. Chris was very kind to gather a bunch of links, which I’ve now read, and I’ve tried to understand.

    But I feel that Chris, you are going to school me today, so we’ll go right back to the basics. The first thing I think to mention is that I don’t think I know anybody else in the WordPress community who is using Composer with the sort of urgency that you feel it should be being adopted. Most of the people that I know are freelancers, possibly working in an agency and the typical workflow is, you know, if you’re working with a team, you’ve got a method of doing that.

    But you may well be working on your own website. You may be working for client websites, and you’re just installing WordPress and a bunch of plugins and themes and so on and so forth. But you’ve got this bee in your bonnet about Composer and the virtues of it. So let’s go right back to the beginning. You’ve probably heard the word Composer before if you’re listening to this podcast, I imagine. But you may not know what it is. So let’s go there. What is Composer and why is it in any way important?

    [00:12:59] Chris Reynolds: At its base Composer is a package management system. So if you’re at all familiar with npm which is primarily for JavaScript packages, maybe you’ve used that for Gutenberg stuff. Maybe you’ve used that for other JavaScript things. Composer is that thing for PHP packages.

    In the past there were things like Pear and PECL, P E C L which did the same sort of thing. Composer does those same-ish things, but better. So at its core, it’s a package management system, which means it’s able to do like dependency management. And what that means is, if I have a package, and I have a certain version of a package.

    Say I want php code sniffing, I can require that package with Composer. I can make sure that package is up to date. But I can also be specific about the versions of that package that I want to keep. Maybe I want to be on PHP code sniffing version eight or eight dot whatever, but I don’t want to upgrade to nine yet, or something like that.

    I can be specific about my version dependencies, the versioning system that I’m choosing and be really, either really explicit. I can pin it to a specific release. I could do, I only want the security or patch releases. Or I could be really vague and say, just give me the latest version of whatever.

    And Composer has, it’s based on the idea of semantic versioning. So as long as your packages and WordPress itself doesn’t use semantic versioning notably, and neither to do a couple other things like Yoast doesn’t do it, because they’re using sort of the version numbers don’t matter school of thought, which kind of breaks the whole thing a little bit.

    But if you’re doing that sort of semantic versioning, which is common throughout just open source software in general, of major dot minor dot patch fr security then you can be really, you can update your things and feel fairly confident that an update is not going to break your thing, break your site. This is perhaps not a myth now as things in WordPress have improved. But the analogy that I like to think of and the reason why feel like Composer is, really important in a WordPress environment is the, I’ve got a million plugins, maybe not a million, maybe 20.

    And I’ve got a couple themes and I go to my WordPress updates page, or maybe it’s got auto updates, right? And something happens and an update happens, and I wasn’t there. Either I bulk updated all of them or it happened in the background. Either way, I’m not looking at each individual update that I’m doing, and something breaks. My website white screens, and I have no idea what caused that problem.

    I have to go back, I have to undo everything. I have to like, rename my plug-ins folder. I’m now in panic mode because my production site is white screening. It’s because of an update. It’s because something went through that I was either not paying enough attention to, or that happened automatically in the background that broke my site.

    Composer, and the way that WordPress is built with allowing, essentially anybody who has access to the plugins page or the updates page to run those updates means that you’re putting the power and the control over administrating code that is deployed to your site, to whoever has access to those screens, right?

    And Composer almost flips that and says, no, we’re going to give this power to people who actually touched the code. Who maybe are more aware of dependencies and change logs and what an update might mean to a site. And that’s, sort of where I, see the value of Composer just broadly.

    [00:16:21] Nathan Wrigley: Okay. That was, yeah, a really interesting description of how it works. Could you give us the nuts and the bolts of that? In other words, could you unpack what’s going on? In other words, how is it, how is it installed? How do you get it to bind to the different variations? You mentioned, that you may want it to update to a certain version of such a thing. How do you actually do all of that?

    [00:16:44] Chris Reynolds: Composer is software that runs on your computer. You can install basically anywhere. So if you’re on a Mac, you might use Homebrew to install it. You can run it on a Windows machine, it’s just a binary. You can run it on a Linux machine, there are packages for it. It’s essentially cross platforms, so you can use it or you can run it anywhere. Once you have it on your operating system. . Then, we’ll just use a WordPress, vanilla WordPress site, as an example, if I had a WordPress site maybe I do wget or download the zip file of WordPress and I unzip the package. Okay, that’s great.

    And then I have Composer on my, on my, system so I can run at the command line Composer in it. And that’s going to start the process of building a Composer dot json file. And then once I have that Composer dot json file, I can start pulling in dependencies. I can say Composer require this thing, this package by this vendor.

    And that’s going to, by default, install my dependencies into a vendor folder. Composer also has a built-in auto loading system. Which means that then in my project, if it’s a WordPress project, I can have a file. I could throw it into wp-content or a rather wp-config, or I can throw it into a mu plugin that loads the Composer auto loader file so that any packages that are being pulled in through Composer or libraries or whatever, are automatically pulled in because Composers does that, just does it for me.

    If I’m doing WordPress specific things, what I would also need to put in my Composer file is a additional repository for W Packagist. So out of the box, Composer works with a platform, a website, a repository called Packagist, and that’s where all of the packages live.

    If you go to packagist.org today, you can do a search and you can find all sorts of stuff. What you won’t find is a ton of WordPress related stuff. You’ll find some. There’s Human Made has a ton of stuff up there, which I know because I worked there. And I’ve put a bunch of Pantheon things up there.

    There’s some other people who have been putting stuff on Packagist, just core like, Yoast notably has stuff up there. But it’s not a WordPress place, it’s just a general open source place, just like npm again. W Packagist is a bridge between the wordpress.org repository and Composer.

    And it is just a mirror of the WordPress plugins and theme repositories for Composer based WordPress projects. So if you add W Packagist as a repository in your Composer json, now I can do Composer require and I can say W Packagist plugin slash WordPress SEO. And that’ll pull in the latest version of Yoast SEO into my Composer file.

    Or I can say Composer require P Packagist theme 2010, and it’s going to pull in the 2010 theme, of most recent version. That’s sort of a little bit of the nuts and bolts. That’s how the Ccomposer json is built. You can also obviously edit this file manually. And then if you want to get into versioning, when you pull that stuff in, it’s going to give you a sort of its default. Which is typically the major dot minor with a little caret before it, which means that it’ll accept all minor versions, but it will pause if the version number, the latest version number changes for the major version, right?

    if it was like 1.5, 1.6, 1.7, 1.7.2, .3, .5 point whatever, all of those things would get pulled in. But as soon as that 1.7 turns to 2.0, because maybe they made a major release, it’s not going to get 2.0. It’s only going to be one point, whatever. Until I change that in my Composer file.

    That’s sort of the default setting. You can be more specific. You can go all the way out to the minor point release and just say, the only updates I ever want to get are these minor or patch releases. To make sure I’m getting all the security updates or whatever. And not getting minor version updates because maybe I’m afraid that one of those minor updates might do something bad, or I’m not, prepared for it yet. Or you can be very vague, and say, just star and give me everything. Or you could say just one, no points, just caret 10 or something. That means that anything above version 10 you’ll get, doesn’t matter what the point release is.

    And that’s a way that you can solve for that white screen of death scenario that I talked about earlier. Because if I’m being specific and explicit about what versions I’m allowing in my updates then I’m not going to, I shouldn’t get to a point where something unexpected happens because of an update that happened that ran on my system.

    And in addition to that the way that those updates happen at all is by me or an automation system running a Composer update command. And that’s the thing that says, go look for things that have changed and pull in any differences based on my defined versioning scheme.

    [00:21:21] Nathan Wrigley: So you can get really granular with it. You can instruct it to do whatever you choose to do. I like the example there of pausing at the point release. So instead of going from 1.9 to two automatically it just pauses because it’s two. But 1.8 to 1.9 was okay to do. Yeah, it’s really interesting, you can get really granular. And then you run the command to run all of the updates and off it goes.

    It sounds like, I could be wrong about this. It sounds like you could broadly break down your description for why to use Composer into three things. I’m thinking, first of all, security. It sounds like it provides, it’s not really providing security, but it’s providing security in the sense that it’s going to update plugins and themes and whatever else you may have coded yourself. It’s going to do that without your intervention. It’s going to run on a schedule and it’ll just get those things updated for you.

    Which as we know in a lot of cases, a lot of WordPress websites, I don’t think the updates are happening for weeks, possibly months, who knows, maybe even years. So all of that gets taken care of. It also sounds like there’s a big time save here. If you can get this into your workflow, then you can step away from the dull task of updating things. This will just happen on the fly. You could have a setup in Composer that you reuse over and over again on a sort of typical website that you might set up.

    And thereby you can just drag in all of the packages on day one of the project. And within moments you’re up and running with a typical install that you mentioned. Suck in a particular theme or suck in a particular SEO plugin or what have you. You just run the Composer and all of that is just dragged in and you’re off to the races. It’s a quick way to get started.

    But also, you didn’t mention this, but it feels like this is a real win for teams. It feels like a team using this workflow, there may be benefits there. So broadly speaking, I’m talking about teams, times and security. Is there anything in that? Have I sort of got that about right?

    [00:23:16] Chris Reynolds: Yeah, I think so. Obviously there needs to be an automated step somewhere in the process of actually running the Composer update. But beyond that, yes, absolutely. And interestingly one of the things that you touched on maybe accidentally even, the idea of sucking in all of these different packages. When I was at Human Made, I worked on Altis, and Altus is their digital experience platform.

    And Altis is built almost entirely on Composer, and lots of cool Composer things happening. Altis itself is what’s known as a meta package. When you install Altis, the initial Composer file is just linking out to a whole bunch of other projects or packages that it brings in. And those themselves have their dependencies. So each, each of the modules, like the security module or the core module or whatever, each of those has its own set of dependencies that it pulls in. So it, really does just sort of like package a whole bunch of stuff that you get just for free when you initially set up a new site using that.

    And that was one of the things that going from the idea of, oh, I’m just going to throw this Composer file in my WordPress site and call that good. That’s one of the things that really made me think, oh, actually there’s, there’s a lot more to it here. And one of the things that I first was exposed to when I was working at Human Made, and that I’m actively doing now with what I’m working on a Pantheon, is the concept of WordPress itself being just a dependency of your project.

    And so like with the initial example, I’ve got a WordPress site. I unzip it. I throw my Composer, json in the root folder. That means that I’m using Composer probably to manage my plugins and themes, any other packages I might have. But I’m still using WordPress itself to update itself. Because WordPress is still part of that root directory, and it’s not part of the Composer structure.

    There are projects, there’s a couple things out there in the world that’s already, that have been existed, but one, a big thing that’s been part of the WordPress ecosystem for a while is by the Roots team called Bedrock. And that’s what we use at Pantheon. And that, among other things, what Bedrock does is it pulls WordPress in so that it can be a dependency. So that can be just another thing in your Composer file that is being versioned.

    So again, same rules apply, right? You can say I want everything past six. You can say I want 6.1 dot anything beyond that. Or you can say, I only want 6.1.1, and when the next version comes out, I’m going to manually make that change so that I can be explicit about my testing process to make sure that I’m not going to ship broken code.

    [00:25:42] Nathan Wrigley: Yeah, that’s really interesting. The idea that WordPress itself is a package. Okay. I can imagine, given the audience of this podcast, it really does span the whole community, you know. There’s people in every part of the WordPress ecosystem listening to this. And I can imagine there’ll be a certain proportion of them who as soon as you start to say things like npm and packages and all of this, and you mentioned, you know, things to do in the command line and da, da, da.

    They’re scratching their heads thinking I don’t know if this is for me. This all sounds a little bit complicated. So just address that. There’s a certain level of tech geeky here, I would imagine, But, is it difficult? Is the payback for a, let’s say a user who is just playing with five or six sites, they’ve got a few client sites and they can well manage to go in and update the plugins and the themes and all of the bits and pieces that they got set up.

    Is there a use case here where, okay, if you’re sitting on that side of the fence, don’t even bother? This is probably not needed. Whereas if you’re on this side and you know you’ve got more sites than a certain number where it’s going to be of more use.

    [00:26:47] Chris Reynolds: I mean, I definitely think that a lot of the freelancers that I know when I talk to are of the mind that, it’s just one more thing I need to worry about. And certainly if you are not going to on behalf of your clients go in and make updates, and you’re handing, once you’re done at your site, you’re handing that responsibility off to them.

    It’s going to be too much work for your clients probably. I’m thinking like small business. I’m thinking like mom and pop shop. That sort of thing where it’s really just a user, one person or two people that are running the site. They’re probably not going to want to do stuff on the command line and you’re not going to want to train them and that’s fine.

    But I think about when I was at WebDev and we were doing maintenance contracts with clients, and WordPress updates came around and we had basically a person dedicated to reading all of the change logs of every plugin on every site before making any updates. Just to make sure that nothing was going to happen that could potentially break.

    And then if there was something that was maybe potentially breaking, they would have to like manually test that themselves on a dev environment, or a local environment or whatever. Just to make sure we’re not going to run an update and it’s going to break something. And I think that that process is very tedious and time consuming.

    And that process is the process that you’re saving by using something where you can be more explicit like Composer. And you know that your updates are not going to break anything because the way that you’ve set up your versioning is the thing that you want it to be, and you feel confident about that structure so that when there are updates, you can go in and yeah, you still need to do testing, you still need to evaluate those things, but you know that you’re not going to accidentally push something out.

    Or you can be at least fairly confident that you’re not going to accidentally push something out that’s going to break something. Because breaking things is not a good thing. It’s not a good feeling to have shipped something when you’re just doing a maintenance WordPress update release and your client is calling an hour later saying, why is my website white?

    [00:28:42] Nathan Wrigley: Yeah, I guess in the case of some of the agencies where you’ve worked, so Human Made WebDevStudios and so on, it really is enterprise level stuff, and there is no scope for bringing a site down because of a careless update. So the notion that most WordPress users would go in and read the change log before clicking update.

    I think that’s probably not the case. I would imagine most people are fairly cavalier because it’s their own site, or it’s a client site that they’ve got a backup of, and there’s some mitigation that they’re, doing all of that. But in the case that you’ve just outlined where, I don’t know, maybe these are international brands that we’ve heard of where the press damage alone in having a website go down for 50 minutes is just unconscionable. You’ve got to do the background research, and so having these systems in place is truly important.

    [00:29:36] Chris Reynolds: Yeah, for sure.

    [00:29:36] Nathan Wrigley: In terms of, we’ve been talking quite a lot about updates. I just wonder what your thoughts are on the, I mean, it’s not that recent, it’s several years ago now. The idea that in WordPress you can click a link in the, let’s say the plugin page. And you can say just go on, update. Whenever something new rolls out, just get on with it and update it. So you can, if you like, trust it. What are your thoughts on that?

    [00:29:58] Chris Reynolds: I think it’s nice for the people that it’s good for. And I think it’s definitely helped with WordPress adoption. Because if all I was doing, if I wasn’t a WordPress developer and all I was doing was being a podcaster and I had a website that was just about my podcast. I’m not going to care about code. I’m never going to want to touch the code. I’m going to want to install WordPress and never look at FTP, or know my server configuration, or care about my database.

    None of that. None of that is interesting to me. What I want is I want to plug it in, turn it on, and let it run. And be fairly confident that it is going to continue to run when I have my eyes closed and I’m not looking at it. So I think that it’s nice in the sense of creating an ecosystem in which things that you do in WordPress are relatively easy. And the counterpoint to that, I work at Pantheon. Pantheon’s been involved in the Drupal committee for a very long time.

    Talking earlier too about how Drupal has, I think since version eight, integrated Composer into the core of how Drupal works. So sort of the antithesis of this idea of, I’m going to turn it on and set auto update and then walk away, is the idea of Composerizing everything. So that every change is a code level change.

    And what I’ve found interesting, that I’ve learned over the last year of being at Pantheon in a difference between the sort of like Drupal ecosystem and WordPress ecosystem, is in WordPress, yeah, there are some people who make it their job to kind of do just general site administration for people.

    But it’s not a huge thing. It’s like there’s a couple people that do that sort of thing or they don’t actually touch the code, but they will do your WordPress updates and that sort of thing for you. In Drupal, there’s entire agencies where all of what they’re doing is essentially that, just the maintenance stuff of having a website.

    And part of that is because the Drupal admin is a lot more complicated to use, to create sites and pages and views and all sorts of things. It’s a lot more complicated than the WordPress admin, which I credit to how WordPress is built personally. But the other part of it is the understanding of like, when it’s okay to update this Drupal module to the next version or that sort of thing. To be aware of what’s happening on their other sites. And then what combinations work together and that sort of thing.

    There’s a whole ecosystem that it’s really just essentially website management, which doesn’t exist in the same way in WordPress. And so that’s sort of what we’re talking about. The difference between having really hands-on updates. Making sure that things are safe to do. Or making it so that the people who actually do the content editing or other administration on the site, they don’t have to worry about the stuff that’s happening in the background because they know somebody’s taking care of it, versus having just the software take care of that for itself.

    And so I think there’s a place for it. And I think that the reason why WordPress has grown so much over the last many years is because it’s embraced this, well, we’re going to just auto update things and not have people stress over that stuff. But, also like the reason why there’s so many people that are holding onto Drupal is because they want to make sure, they want to ensure that their site is stable and secure and all of those things. And that those things matter for really big companies. It is that divide, right of more casual users versus the enterprise level stuff.

    [00:33:09] Nathan Wrigley: I guess because Composer is essentially nothing to do with WordPress. I mean, you know, you’ve described a scenario in which WordPress can combine with it, which is very helpful. Updating plugins, themes and so on and so forth. I guess this can reach beyond WordPress. So if you’ve got something bespoke, unique, you’ve got a package, which is nothing to do with WordPress. Composer can take care of that as well.

    [00:33:34] Chris Reynolds: Yeah, and it’s really useful when you, so in both npm and Composer, there’s the concept of dev dependencies. And these are dependencies that will install when you do like a Composer install. But you can also say, you can omit the developer dependencies on your production installs, right?

    And that means that you can run things like linting and unit testing and all that sort of stuff, which doesn’t matter if it’s on the prod site. But maybe if you’re going to push it to your dev site or you’re going to keep it on your local machine. And you can manage all those things really easily with Composer.

    There’s definitely WordPress coding standards and there’s WordPress suites for unit testing. Those things all exist and you can manage those in WordPress. But essentially, like the core thing, like PHP Code Sniffer is not a WordPress thing. It’s just a, it’s just a package that exists in the world. And same thing as PHP unit. It’s just a thing that exists in the world that we have adopted and embraced and brought it into our ecosystem. So for sure, yeah, there’s definitely value of using Composer to manage sort of like external things.

    [00:34:29] Nathan Wrigley: Okay, given that if you went down this route and you made Composer an integral part of your process. You then to some extent become dependent upon the functioning of Composer for your whole process to work. And so that brings me to the Composer ecosystem.

    So we’re all always talking about how great the WordPress ecosystem is. There’s a forum for this. There’s a Slack channel for that. If you want to find something out there’s ways of learning. Is the same true of Composer? It’s an open source project. Does it have a thriving community? Does it receive the updates that one would hope? Does it progress in the same way that we hope WordPress does? Does it have that same feel? Are there resources for learning and so on?

    [00:35:07] Chris Reynolds: Well, I will say that the website for Composer getcomposer.org, I believe, is really, the documentation’s really good. At its core, it’s a pretty simple idea. The documentation’s pretty self-explanatory. Where it gets hairy is the distinction between a caret versus a squiggly line, in terms of how you’re going to do your versioning stuff.

    Because there’s a very subtle but specific difference there. And how to pull in different repositories or how to do more complex things. It gets a little bit hairy. But again, the documentation is all there and it’s all really good and I found it very useful.

    And there’s enough people in the open source ecosystem generally that are using Composer, that it’s not terribly difficult to find answers to any questions about Composer. Most things you would encounter have probably been done by someone, and there’s probably some prior art that you can use to base it on.

    So I think that it’s generally pretty good. And packagist is a great place to find stuff. What I will do when I’m looking for stuff is I’ll look on packages, even if I’m looking for a WordPress thing, just to see if, if that developer has pushed their thing to packages before even looking at wordpress.org, or pulling it in from the W Packagist mirror.

    That means it’s getting a little bit, it’s like one step closer to the source, right? Because all Packagist does really, to submit a package on Packagist, here’s your pro tip. You have an account obviously, and then you just say, submit a package and you give it a GitHub repository url, and then it just looks at GitHub. And as long as the GitHub project uses releases, even if it doesn’t really need to, it just looks at the branches. But if it has releases, then you will have those versions. And if it doesn’t have releases you can still pull that stuff in using a dev prefix or whatever.

    That stuff is all self-contained. It all exists. It’s all well-maintained, all that sort of stuff. That’s all good. Composer itself does occasionally get updates. The last big thing was sort of a transition from Composer one to Composer two. And that was a little bit of a, there’s definitely some growing pains in the transition process of going from one version to the next.

    And then they threw a wrench recently, not super recently. But they threw a wrench into things a little bit where there is a new thing that goes into your Composer file called allowed plugins. So if it, if it’s a dependency is calling something else or whatever. You have basically have to give permission to other vendors to, install things on your behalf. So as long as you, if they’re in the allowed plugins list then those things will get updated, and if they’re not in the allowed plugins list, then it’s not going to update those things. And I believe that was for like, security type things.

    That did cause a problem with you know, at Pantheon we have a lot of stuff that’s based on Composer and we don’t want to introduce merge conflicts. So if we have a Composer file, that is basically the thing that is used to build sites. And then suddenly that Composer file needs to have a new part of the Composer file, and we push that change. It’s going to cause a merge conflict with everybody’s repository that didn’t already have that.

    So it’s a little bit of a headache for us, but for the user it’s obviously a net win. Those sorts of things give me pause a little bit, as somebody who is now at least partially responsible for, thousands of people running sites that use Composer. But in terms of like individual users and stuff, I think that Composer has a really good thing going and has a good ecosystem around it.

    [00:38:16] Nathan Wrigley: Just to give us some insight into how you are using it. Your work at Pantheon and all the other companies that you’ve mentioned that you’ve worked at. Is this something that is just typical? This is just part of the process. Everything is built with Composer bolted in. Or is this something that you cherry pick? Okay, this one needs it, this one doesn’t. Is it basically everywhere, all the time?

    [00:38:38] Chris Reynolds: When I was at WebDev, which admittedly is many years ago now, we didn’t use Composer. We could have benefited from using Composer. And I think they’re probably using Composer now. I don’t know that for sure, but based on the types of projects that they’re doing, and types of things that I see them working on, I think that’re probably doing it now.

    When I was at Human Made, it was just there. Everything that we did had Composer as part of it. And it was a sort of a fundamental part of how projects were built. And obviously like Altis is Composer. It’s a Composer built thing. It’s entirely built on top of Composer. One of the things that gives it its stability, but also if you look at the documentation for Altis or things, it’s always lagging, and is always going to be lagging a little bit behind the latest WordPress release.

    And for enterprise, that’s fine. Because they’re not concerned about the major or minor point releases. They’re concerned that their site is secure and it’s updated and it’s getting those patch releases. So with each new Altis version that typically aligns with a new WordPress version it sort of, when I was there anyway, the release cycle for Altis followed by a month or so, offset from the last WordPress release, so that they could make sure that the next WordPress version was part of the next Altis version.

    [00:39:48] Nathan Wrigley: Okay, so should somebody have been interested in this, you know, their interest has been peaked by everything that you’ve been saying. Where’s some good resources? I’m looking at getcomposer.org and there’s a get started link right at the top. That seems like it might be a decent place to start. But maybe there’s more, how to describe it? Maybe there’s some things which would help a WordPresser as well.

    [00:40:13] Chris Reynolds: I definitely would point towards the Roots Bedrock Project as being a really good place if you’re looking at wanting to have WordPress as built as dependency, I think they’ve got a really good framework. And at Human Made, we were doing that thing, but we weren’t using Bedrock. So it would be a little bit more difficult to come up with those ideas and that system and that framework independently. And that’s one of the things I think that you would get from the Roots ecosystem. So definitely yeah the, just the get Composer to learn about it and to look at the documentation, to dig into it.

    And then from a WordPress standpoint specifically, I would definitely look into Bedrock to understand like how that works. And they’ve got a thriving community as well around that. And, a whole Patreon thing and Discord channel and whatnot, so that you can actually talk to human beings and get some amount of support.

    [00:41:02] Nathan Wrigley: Yeah I’ll make sure to link to everything that you sent in my direction into the show notes. But, if anybody wants to check those out, you can see them on the WP Tavern website. Search for this episode, and you’ll be able to see all of those links there. If anybody wants to link to you Chris, if anybody’s been interested in, just think they’d like bit of a helping hand. They’d like to understand this a little bit more from, from the horse’s mouth if you like. Where do we find you?

    [00:41:27] Chris Reynolds: Online I’m jazz sequence most places. Frequently jazz sequence with a three. So j a z z s 3 q u e n c e. That’s my Twitter handle and Instagram, various other things. I am at @jazzsequence@mstdn.social on Mastodon. And, my website is jazzsequence.com without the three, cause I like to, be confusing. And LinkedIn and places like that. But the Twitters and lately Mastodon, and those sorts of social places where you’ll probably get my attention.

    I’m also, you know, on the WordPress Core Slack and like I said I live in Salt Lake City so, we haven’t had very many WordCamps in the last couple years. There’s some weird pandemic thing happening, but when those things do happen I often will try to visit the things that are, within driving range. I’m hoping to be at at US in National Harbor this year. So, maybe I’ll see folks there.

    [00:42:16] Nathan Wrigley: Nice. Chris Reynolds, thank you for joining us on the podcast today. I appreciate it.

    [00:42:20] Chris Reynolds: Yeah, no worries.

    On the podcast today we have Chris Reynolds.

    Chris has been working with WordPress for over 15 years. He’s freelanced, worked with Event Espresso, WebDevStudios, Human Made and is now at Pantheon as a CMS Ecosystem engineer, and WordPress technical lead. He’s spoken at WordCamps and at OpenWest about all aspects of WordPress.

    I suspect that many of the people listening to this podcast are not using Composer in their WordPress workflow, and to Chris, this is something that you should think about implementing, and he’s here to explain why.

    Chris starts off by talking about the kind of projects that he’s worked on, and how he found WordPress.

    We then get into the weeds of what Composer is, and the benefits that it brings. It’s essentially a package management system and makes it easy to set dependencies for your project and manage them within Composer.

    Why would you want to do that though? If you’re just building brochure websites, then perhaps you don’t, but if your project is more complex, then this might save you a lot of time.

    Chris describes scenarios in which he thinks Composer is a good fit; if you want to add in specific packages, and how those packages are managed and updated.

    He explains how you can install Composer depending on the OS that you’re working with, and how it structures the files and directories that are created.

    Towards the end of the podcast, we talk about how Composer can be useful for teams, and Chris’ use of Composer to keep everyone clear on how the project is structured.

    If you’ve thought about using a package management system such as Composer, this episode is for you.

    Useful links.

    Hot Scripts

    Event Espresso

    Pluralsight

    WebDevStudios

    Human Made

    Pantheon

    npm

    Homebrew

    WordPress Packagist

    Packagist

    Bedrock by the Roots Team

    Composer

    Chris’ Twitter account

    Chris’ Mastodon account

    Chris’ website

  • #67 – Talisha Lewallen on How CertifyWP Is Hoping To Offer WordPress Certification

    Transcript

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, what a WordPress certification might look like.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast, player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you all your ideas featured on the show.

    Head to WPTavern.com forward slash contact forward slash jukebox, and you use the form there.

    So on the podcast today we have Talisha Lewallen.

    You might have found your way into WordPress intentionally, or perhaps you stumbled across it and decided to explore further. Whichever it was, you’ve learned things along the way. Some of it might have been through training, but there’s likely been some self discovery on the way as well.

    Perhaps you’re a coder, or a designer. In fact, there are dozens of different pathways in the WordPress ecosystem. Given the broad range of knowledge you might possess, how can you prove that you know what you know?

    Many industries provide training programs which, when completed successfully, allow you to assert that you were competent in a given area. You’d want your lawyer or surgeon to have passed through the appropriate programs of study, so that they’re equipped to do the work.

    With WordPress being such a dominant force in the world of websites. Would it be a good idea to have a certification for WordPress? Talisha certainly thinks so, and has founded CertifyWP to try to make that happen.

    We approach this subject through the work that she’s been doing at WPConnects, in which she’s been trying to provide training to military veterans, so that on the departure from the services they have the prospect of finding work in the WordPress space.

    We talk about whether there’s a need for certification for WordPress and how such a certification would come about. What levels of training does Talisha see as essential, and how many such layers might there be?

    We discuss whether the WordPress community is ready for a third party to be certifying people’s abilities, and whether this strays away from the approach that we’ve had so far in which routes into employment have relied on other, less formal, methods.

    Later in the podcast, we talk about the structure of CertifyWP, and who’s behind the project. You’ll hear that it’s not just Talisha. There’s quite a few members of the WordPress community who want this project to succeed.

    If you’re curious about certifications in the WordPress space, this podcast is for you.

    If you’re interested in finding out more, you can find all the links in the show notes by heading to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

    And so without further delay, I bring you Talisha Lewallen.

    I am joined on the podcast today by Talisha Lewallen, Hello Talisha.

    [00:04:00] Talisha Lewallen: Hi Nathan.

    [00:04:02] Nathan Wrigley: Very nice to meet with you. You’re welcome on the podcast. Thank you for joining us. Would you mind just introducing yourself and give us some indication of what you do, perhaps who you work for, and how come you are in any way connected with WordPress?

    [00:04:18] Talisha Lewallen: Yes. I am Talisha Lewallen. And I am the owner of WPConnects, which is a company that helps US military veterans or really any veterans, but helps them receive training while they’re active duty, and then when they’re separating from the military we provide them with mentors and help them find employment within WordPress.

    And then I’ve also started this new venture with some very amazing people within the WordPress community called CertifyWP Foundation. And that is where we are creating a couple of WordPress credentials.

    [00:04:51] Nathan Wrigley: So we’re going to talk about both of those endeavors today, but I think probably the correct road into both of those subjects is if we begin with WPConnects. Now, you mentioned that this is a company that you are the founder of. It’s got a mission, it’s connected with the military, but in broad outline really, it’s a, it’s an endeavor to connect people who are looking for work and are in need of guidance. Do you just want to tell us how all this started and what really the bedrock, the core philosophy is, and who you are helping and how you are helping?

    [00:05:26] Talisha Lewallen: Yeah. So I worked at Post Status for a little while, and while we were over there, we kept hearing a lot of people state that they really needed some trained WordPress developers and employees. And so that really got us thinking, you know, it’s one of those twist of fate things, that we ran into a gentleman named Hector who has a similar company to WPConnects.

    And he’s definitely been a very big mentor to me. So when service members go in and sign up to join the military, a lot of times they’ve never had an interview, they’ve never had job experience, they’re literally just starting their career. Well, when they get out there are transferable skills, but not a lot employers are looking for, if that makes sense. So we want to provide them with, it’s called transitioning assistance. And we want to provide them with that training and so it helps them transition into the civilian sector a lot easier. There’s different skills that, you know, we do over here. And then we’re training them for WordPress front end and backend development.

    And if they wanted to do anything else in WordPress. You know, it’s really expanding past just developer careers. And so we’re just really helping them find the right connections, along with mentors who have been where they’ve been and can help them transition and really just know that experience.

    And so it really just comes from a place of, I have several members in my family that were in the military, and seeing them transition out of the military was kind of hard. I took the general route over here and I went to high school, college and then started my professional career and seeing my family members and friends join the military, and then when they get out and they had these amazing jobs in the military. They had all of this training and then they get out and they can’t even get a job.

    I heard one of my friends tell me the story of a gentleman who was a military police officer and couldn’t get a job as a police officer here in the States. And it’s because he didn’t have, in that town, you had to have an associate’s degree. So he didn’t have the training to become a police officer when that’s all he did for 10 years in the military, was be a police officer.

    And so it’s very interesting to see the skills that they have and the jobs that these men and women have had, and then transferring it into civilian life. It’s just not, or hasn’t been there. They’ve just been struggling to find these employment. And so we’re really just reaching out a hand and saying, let us help you and let us get you introduced to these amazing people inside of WordPress. WordPress has the best community that I have ever been a part of, and so it really just seems like a good fit for them.

    [00:08:04] Nathan Wrigley: Can I ask, do you give them a curriculum which they follow? In other words, have you mapped out, in the same way that a university may do, you know, you’d attend a university and you would fully expect that they would provide you with the course and they’re not just making it up on the fly? Or is it more working with them to try and figure out what they need? It might be a mixture of both. I don’t know.

    [00:08:25] Talisha Lewallen: Yeah, so how we do it, we have three pathways right now. And this is what makes WPConnects very unique, even within the military training field. So there’s a saying in the military that’s crawl, walk, run. So you’re not just going to get something and immediately start running. So our steps for crawl, walk, run are these three pathways.

    The first one is the credentialing assistance program. Active duty and reserve military personnel are able to take a credential and it is funded through the military, so it does not cost them a dime. And they’re able to take this training. So we currently have the web foundation associate credential. And this is also where CertifyWP comes in.

    So currently we’re using that WFA course. So once they complete that and they decide to transition out of the military. It could be the next month, whenever their service contract’s up. It can be two, three years later. Whenever they are transitioning out in the last 180 days of their service contract, they can join what’s called a Skill Bridge program.

    So we also have a WordPress Skill Bridge program. This program is an instructor-led 12 week course. And it’s all over the US. We do it over Zoom, and we’re looking at a few other platforms. But again, it’s that instructor is there. There is a curriculum, and they are learning how to, mostly that one is backend development, is what they’re learning currently.

    And then whenever they finish that, we just opened up an apprenticeship program in Texas. And we’re about to open one in Oklahoma. And so it’s just this three step process. The apprenticeship program, they have certain skills that they will acquire throughout the year long apprenticeship program. And then they are 100% ready to be employed and be able to do any job that they’re really wanting to do, because we will give them that individualized skill.

    And through all of that, they have a mentor that they can reach out to, and the mentors reach out to them and just help them with anything they’re struggling with or have questions about. There’s different terminology that we use in civilian life than they’ve used in the military. And so really that person’s just to be there, to just have a helping hand.

    But yeah, it’s a little bit of both. We have a pathway, we have curriculum. And we do change our curriculum. We get feedback from other people within WordPress. Nikki with Liquid Web has been the biggest help for our Skill Bridge program. She comes through and interviews and mock interviews just about every person we have in our programs and helps give us feedback so we can help them gain those interview skills. We have them write a resume and then I go through and help them work on their resume, so then they have that resume whenever they get out as well.

    [00:10:59] Nathan Wrigley: I guess if you are in a different industry, there may already have been for a great deal of time, there may have been institutions or pathways like this already set up. You mentioned the example there of the police and that pathway not really working out. But presumably there are other ways that people leaving the military can go and there’s things that are already concrete. Institutions that they can join. Companies that they can join. Programs that they can go through. But not in the WordPress space.

    And given WordPress’ 43, and counting, percent share of the internet, it’s a really credible career to go in, but it’s a difficult thing to, I would imagine, to even understand. If you’ve never touched the internet before, apart from being a user and a consumer of the web, you may have no skills or whatsoever.

    So I’m guessing it’s bridging that gap. Trying to persuade people that actually there’s a job in here. It’s an in demand job. Can be well paid and a good career path, and there’s a nice community behind it all as well.

    [00:11:57] Talisha Lewallen: Right. And you know, we have some people that are literally, I’ve never touched a computer before. But we also have people that come through the program that have been a part of the satellite operations within the military, or have done tech in the military. But getting that pathway to employment is what they really need. And learning WordPress. There’s a lot that goes into WordPress that we want our individuals to learn and that will help them grow within whatever job they decide to do. But yeah, so we have two opposite ends of the spectrum usually. We have the ones that have a ton of tech experience, or the ones that have no tech experience.

    [00:12:33] Nathan Wrigley: So that was a really nice introduction into the why really, for the next bit of the podcast, which I think will consume the rest of the show. So we’re going to talk now, instead of talking about WPConnects, we’re going to talk about credentialing in the WordPress space. And maybe I’ll begin this way.

    If I were to attend a university that everybody’s heard of, let’s say I’ve been to, I don’t know, Harvard or Cambridge or somewhere like that. That credential that you hold, it’s a real passport. Everybody understands what that means, and you present it to employers and they get, okay. Right, you’ve been to a university, we know what that university is about. We understand that it’s been around for a while and, that’s a credible piece of paper that you are holding. But curiously, in the tech space, there are things like this, but specifically in the WordPress space, there’s nothing like this.

    There’s a great big hole there, isn’t there? So people who wish to be employed, going to an employer, you really are relying on testimonials, the CV, the reputation that you’ve got from your previous employer, and the letters that they may write on your behalf. But there’s no bit of paper that you can hold, going in cold, to say, I’ve done this. Look, there it is. It’s certifiable. This is what I’ve achieved.

    [00:13:51] Talisha Lewallen: Yes. And you know, that’s what we’re kind of finding out on both ways. Having a credential helps both employers and people looking for employment, especially within the WordPress space, without having that credential. There’s a lot of people that I would say could very well do certain jobs. But because there’s not that level of credentialing and there’s not that standard education.

    What does a WordPress developer mean? What can you do if you say you’re a WordPress developer? And that’s what a lot of companies are running into. So it really is almost word of mouth. Sometimes I feel like I should say that it’s almost word of mouth for you to get hired, because somebody’s worked with you and knows your level of skill. If you’re new to the WordPress space, it could possibly be harder to find a job because nobody knows who you are, your work ethic and what your skillset is.

    [00:14:39] Nathan Wrigley: Yeah. So that’s the premise behind all of this. So I guess I should ask at the beginning, what level are you going in at? Because really in the WordPress space, we could probably come up with 50 curricular that people could follow, probably more. We could have things on the hosting side, speed optimization, SEO, backend WordPress. The sky’s the limit, but I’m presuming. That in the scenario that you are dealing with, mainly it’s getting started?

    [00:15:08] Talisha Lewallen: You know, that’s the interesting thing. So we, so we have the advisory board. I should say, whenever I first decided this is something I want to do, I really want to make this credential. I reached out to several people, because I kept hearing nos and yeses, and so we put together a team of an advisory board and we had this conversation.

    Because originally I was thinking about one credential, that would have three tiers. So now we’ve decided on two. We’re going to have a front end developer credential and the backend developer credential. So each one will have three tiers. So it starts at base level of here’s how I download a WordPress. This is how I can add admins. This is how I do, you know, very, very basic.

    Then there’s the next level, and then there’s the expert level. So to obtain the credential, you must pass, it’s either one cumulative exam, or you could take it with each course. So you take that exam that has all three tiers of those, and that’s how you obtain that credential.

    And that’ll be on the backend credential too. It’ll have that three tiers again, crawl, walk, run. We’re not going to expect you to be able to do it if you’ve never been taught the why behind it. So with that being said, one conversation that I had with a gentleman was, well, you know, it almost turned into some people can take tests, but some people can’t. That doesn’t mean that they’re able to do the job. And I said exactly, and that’s where we are trying to find a way. It’s still, still alluding me a little bit, but we are trying to find a way to have a practical part to the exam, in the top two tiers.

    The first tier exam probably will just be question and answer type exam. But in that expert level, I want there to be a practical part of it. To have people show that, yes, I did learn how to master this skill. And yes, I can do this. And so I think that that’ll help. Also with the credential and why it’s, I think, beneficial to WordPress is, you know, WordPress changes sometimes.

    We have big changes, we have small changes. So there’s a certification that you can take. And that can just be a course. Anybody can come up with a course. I could just go to my back room and be like, this is what I think somebody should know for WordPress and create this certification.

    And then I never have to re-certify. I never have to go back in and show that my knowledge has not waned, or that I do still know what I’m doing, and still have that level, just standard level of education. With a credential, there is an advisory board and a board of directors and you have to re-certify every three years, to show that you are still maintaining that knowledge. So it’s not 10 years down the road, oh look, I took this and I’m still here. You’re able to show that you still maintain that level of credentialing.

    [00:17:53] Nathan Wrigley: That’s an industry practice that I’ve seen before, especially in things like networking. And I mean networking in the sense of cables and connecting routers. The organizations often behind that will require you to come back after a given period of time and re-certify yourself. Just because otherwise that credential kind of loses all meaning, because the technology itself has moved on so far in the three, four however many years. That if you claim to know from 10 years ago what’s required to be known today, there could be a complete mismatch. Okay, that’s really interesting to know.

    [00:18:25] Talisha Lewallen: There’s been a lot of thought that went into this credentialing. Along with having, you know, just what I would consider WordPress experts that are being there and really talking about what they feel somebody should know in the WordPress for each level of the credentialing.

    But, let’s see. I think JavaScript has a credential that you have to re-certify. If you’re a nurse, here in the US you have to re-certify your knowledge. Car mechanics. You know, so there’s a lot of credentialing out there in every industry that does have that continuing education piece. Just because things do change, the world changes so much, and it’s very beneficial.

    [00:18:58] Nathan Wrigley: So given that you are hoping to find people who wish to take these credentials. Is it open to anybody? We know that your background was connecting with people leaving the military. Is the intention of CertifyWP, and of course I should have mentioned the URL. The URL that you’ll go to, which of course I’ll put in the the show notes is certifywp.com, as you’d imagine, it’s all spelled in the typical way. No, no underscores or anything like that. Is the intention that these certifications will be open to everybody? Or is there a subset of people? What’s the audience for this?

    [00:19:37] Talisha Lewallen: So the audience for the credential is everybody. CertifywP is for anybody and everybody to take. Our hope would be that companies start looking at their credential and stating that, yes, I want to hire people that have this credential because we know they have this baseline education. So it is open to every single person.

    The baseline, the level one certifications I hope to get into some smaller communities. I live here in Oklahoma and so there’s a lot of Indian capital technology centers and stuff like that, that I would really like them to start taking these credentials and really trying to help the minority groups get more into WordPress as well.

    But one thing that has confused a lot of people, and I have to say that this is definitely my fault. I expect everybody to be on my brainwave sometimes. The mention of the DoD, the Department of Defense has thrown a lot of people off. And so they think that this is just a credential for the military and that is really the farthest from it.

    And I just have not fully been able to explain that to everybody. But the DoD approving the credential comes in for WPConnects, so that we can train our military. Instead of using that web foundation associate credential, we will use our WordPress credentialing to train them. So they will be trained from the bottom up in WordPress. So that’s where that has came in. But CertifyWP is open to everybody to take.

    [00:21:03] Nathan Wrigley: Okay, so just to clarify that. There was a hoop that you had to jump through in order to receive money from the government to train people from the military, but the training is ostensibly the same, but there’s that slightly strange mixed messaging there. Have I parsed that right?

    [00:21:20] Talisha Lewallen: Yes, yeah. And that’s all it is, is for our military members to be able to take the training where the government pays for it. They have educational grants and stipends in the Army and Air Force, especially here in the US that they don’t have to take those, they don’t have to pay for those credentialing. So for us, for them to be able to use those monies, our credential has to be approved through the DoD.

    [00:21:43] Nathan Wrigley: Speaking of money, that’s an interesting segue for a minute. Is the intention for this then to have a fee bound to it? In other words, if you want to take this credential and receive the training materials and the time of the tutors and all of that, that there’ll be a fee attached to it? And, if that’s the case, do you have plans to have scholarships and things like that? Is there any of that afoot even as an idea?

    [00:22:07] Talisha Lewallen: Yes. That’s, you know, partly why we actually turned CertifyWP into a nonprofit, is so that we can offer those scholarships. For the credential to be, I almost want to be, say accepted into definitely DoD standards. But if we ever get it accredited, either, there has to be certain qualifications that credentialing meets.

    So we’re trying to set up CertifyWP credentials to meet the qualifications for, one, the DoD, but also if we ever do decide to get it accredited. And one of them is that it has to meet the standard for financial costs. So, I think there’s even a PHP credential, but the other tech credentials out there, ours will have to match that price.

    But we are going to be able to scholarship people in. That is definitely our hope. Because again, we don’t want this to be a gatekeeping thing of you have to pay to play. Not everybody can do that. And so we definitely want to work with people and companies on just trying to get this credential out to the community and making it affordable for every person.

    And there are ways to do that. The board hasn’t fully decided on one and cost has not even been mentioned yet, just other than the fact that we have to have one and it has to meet an industry standard. But yes, definitely trying to find a way to cut costs down for just the regular person is something that we are looking at, because it can be, they can be quite expensive. And I know that that’s been a talk within, that I’ve seen in the Post Status Slack channels before. Whenever somebody moved CertifyWP into one of the channels, somebody was like, oh, here we go, gatekeeping. And oh, it’s going to cost so much and stuff like that.

    And it’s a very good concern and conversation to have. But our whole intention, and I don’t want to speak for everybody on the board or advisory board, but isn’t to keep it away from people. We want everybody to be able to take it. So we are finding ways to really scholarship and bring people in.

    [00:24:01] Nathan Wrigley: So we’ve talked about the audience, well, one of the audiences or one of the, one of the spokes of the wheel, if you like, for you. But of course there’s another side to this, and I’m, imagining that you really are a bridge between the people who want to be certified and the people who subsequently want to receive the wisdom that you’ve given them, the certification.

    In other words, the employers, the people who are going to be employing the people out the other end. And presumably that’s going to be a challenge that you’re going to face as well, is convincing businesses that look the certificate that we’ve given them the certification that they’ve gone through and achieved actually means something. And I’m guessing there’s going to be quite a lot of your time spent making those people aware that it really is bonafide.

    [00:24:46] Talisha Lewallen: Yes. That’s where having the DoD backing, and also possibly getting it accredited shows that this is a real credential. There are people out there that do see that this credential is a massive benefit. So with that, for us there’s different ways to get it DoD approved, I should say.

    And the easiest way is to have community buy-in. So having those companies state that yes, I do see a need for this education level and to have credentialing. So that’s where on the website we have the endorsement letters. And I know Sophia Desrosiers has been making some phone calls and we have a couple of people that have been reaching out to companies and explaining what we’re really doing.

    Because we’re trying to get those endorsement letters because that will help us get it DoD approved. It’s just showing that there is a need in the community for a credential. Not even our credential. It’s one of those fun little things, but it’s just saying that there is a need in the community.

    And I definitely think once we get our credentials up and running and people start seeing what we have in there, and the education. I really think that a lot of companies will come around to it. The ones that I’ve talked to so far, I talked to one that was a little hesitant and I love that he booked a meeting with me and talked to me about his concerns, and that I was able to, I don’t want to say that I argued my point, just was able to genuinely share what we are trying to do at CertifyWP, which is just to make a community built and maintain credential.

    And he ended up signing our endorsement letter, and I absolutely loved it. But I loved that space to be able to fully explain what we’re doing and how we’re setting up the credential to really benefit not only employers, but the job seeker.

    [00:26:29] Nathan Wrigley: It’s a virtuous cycle in a way, isn’t it? In that if you get people on board and you can take them through the whole process and then they are ultimately employed, and the employers are happy that they can hit the ground running at whatever level that may be. That has a sort of feedback loop to it, doesn’t it?

    After a period of time, the employers will broadcast that message. It will presumably encourage people who are looking for a way to be certified in tech, to hop on board and on it goes. So yeah, that’s going to quite an important part. So you are reaching out to those people and you’re hoping to get some more on board to bolster the whole enterprise.

    [00:27:07] Talisha Lewallen: Yeah, we definitely need more endorsement letters from the community. It could be individuals or companies. The companies are what really the DoD is looking for. But just showing the need in the community. And like I said, I’ve talked to quite a few either hiring managers or companies that have sat here and said, you know, I put out a job description and I need a WordPress developer. And then I pay them the salary and they come in and they can’t do what we need them to do.

    But on their resume it looked fine. And they were able to say these things, but they didn’t have the education that they needed. So then it costs the company more money to have to train this person to be able to get them up to this level, to where if we are able to train them and then you’re able to hire them, and you know they passed this, I hate to say they passed the test, but they’re able to show that their competency is there. It saves companies time and money on hiring.

    [00:28:00] Nathan Wrigley: Speaking of the test, you mentioned that in some scenarios it may be like a written paper or something like that, but presumably the higher up you go on the ladder of difficulty, the more need there will be for practical implementations. And you said that there was still room to be, you’re still trying to figure all that out, and work out what that path might be, but I guess that’d be an interesting subject to pause on for a moment.

    What are your thoughts around that? Testing in some kind of platform that allows you to do code examples on the screen, live. Those kind of things. Just essentially making sure that it’s legit, it’s bonafide, and that the people that are doing it are actually doing it. You could be bringing them into test centres. There’s all sorts of permutations here, isn’t there?

    [00:28:41] Talisha Lewallen: Exactly. And that’s where, right now, I’m looking at LMSs, Learning Management Systems to put the coursework, but also the exam on. And so I’ve been talking a lot with these companies about what this exam could look like with this practical application. And what I hear a lot, and even this has been suggested in conversations with the advisory board is almost having like a capstone, or a project that they complete after they take the written assessment. In having this practical that they turn in.

    And that is always an option, and we might have to go to that. I’m leery about that because then we will have to train and hire people to look at these capstone projects if you will. And determine if somebody has passed or failed it. And so then you run into, well maybe I got somebody that graded my capstone or my project harder than person B.

    I really shy away from that type of stuff and I’d rather have it be computer generated. It’s unbiased. There’s just so many ways you can set that up to where there’s not that fault in there. So definitely the back end and coding one, there will be sides once you get higher up for you to actually code. I’m not a coder, so I don’t want to sit here and use terminology that I don’t understand myself.

    But there is that practical part in there where you’re actually going to go in there and you’re going to do it. The front end side’s going to look, you know, a little bit differently, but still, I’m not a test taker, but I can perform the task and I can do the job generally.

    But then you have other people, and I always use the example of my sister. I love her to death. She’s very, very smart. And she could take a test like nobody’s business, but that doesn’t always mean that she can do the work that she just tested on. It just means that she can have really good memory recollection. But doing the task is not something that is there all the time.

    And so we really want to hit both sides. As well as companies having the confidence that when they hire somebody with this credential, they know that they passed the practical part and they can do it. And so it’s really just trying to find out the best, we’ll say best, most efficient, cost effective way to really have this and what is best for everybody.

    Because what I really don’t want to get into is somebody sitting there and saying, well, I didn’t pass the exam because of, you know, X, Y, Z. And it ended up, it could have been human error. Computers have errors too, and we can work with that. But I just want to take the human error side out of it.

    [00:31:07] Nathan Wrigley: I can imagine there’s going to be a subset of people listening to this podcast who will be thinking there should be no canonical certification in WordPress. We should be open to go wherever we choose. It feels like you would like this to have some sort of backing, if you like. Community backing, if nothing else. Not necessarily official backing. But you’d like this to become a baseline. Something that anybody can aspire to, and anybody can see within the community that this is something which represents a decent beginning if you like.

    Not really sure I’ve phrased that question particularly well, but what I’m trying to say is that there’s going to be some people who say, why do we need this? What’s the point when we’ve been getting along just fine for many, many years? We don’t want one player dominating the market in accreditation and certifications. So we’ll just speak to that for a minute.

    [00:32:00] Talisha Lewallen: Yeah. I’ve had this conversation, it actually might have been on Bob’s podcast. And through a conversation that I had with somebody else, it got brought up to why CertifyWP. Why should a third party be able to have this credentialing instead of either the hosting companies or Automattic themselves, whichever way you want to look at it.

    Why should this third party be able to do it? And my answer is always, why not? We are able to have this just absolutely community built and maintained. I think it gives us the freedom is what I should say. It gives us the freedom to be able to keep it unbiased as possible, to where it benefits the most people that we can.

    Not everybody’s going to be happy with it, no matter what we do, and that’s fine. We’re here to help the most people that we can. So having it community built and maintained just allows for a little bit more freedom to get the information that we see as a community that people need to learn, and have to be able to do the jobs that we are hiring them for, or that we want them to do.

    And so my example, if you go onto Fiverr, and again, I’m not dissing anybody that works on Fiverr or does websites. It is a great platform for you to be able to get contract work. But when you look on there and you look at a WordPress developer, I need a WordPress website. There are, I mean, it seems like thousands of people out there that are like, oh, I’m a WordPress expert.

    And I even saw a couple that were I’m certified in WordPress. And I’m like, no you’re not, because there’s not one. It’s one of those that people that are just an average Joe that’s trying to get their website built is not going to know about the community. That we don’t already have this certification. That we don’t already have all of this baseline knowledge. They’re not going to know.

    And so this credential allows even contractors to hire the right person and know that they have been certified, and that they know what they’re doing and they know what they’re going to get out of the product based off of that. So it really, it’s really just this, I keep going back to community built and maintained, because I want, I really want everybody to know it’s not us sitting here saying that, oh, we have the master knowledge and we, we know what everybody needs, because we don’t.

    And that’s where we are willing to hear your side and your opinion and really build the credential that the community needs and is going to use and finds the most benefit out of. We’re coming from a very big place of love and light and you know, trying just to help. And you know, that’s just really where we’re at at this point.

    [00:34:28] Nathan Wrigley: With that conversation in mind, have you had any collisions with the use of WordPress, because obviously WordPress, the word is a trademark. I noticed that you’re calling it CertifyWP, so you’ve, you’ve sidestep that one, but I wonder if there are any collisions there that need to be avoided.

    [00:34:49] Talisha Lewallen: So, so far, I’ll say now, we have been in contact with Josepha and Matt Mullenweg has been on some email chains. I have not personally got to speak to Matt about these, but Michelle Frechette, fantastic woman, and saves my life every day, I swear. Michelle, and myself had a meeting with Josepha and we sat down and we explained what we are trying to, and it really, I mean it was a very positive conversation in my opinion.

    And so it was never brought up that, I’d hate to say that, you know, we get trademark or you know, cease and desist, but it was really, they were just trying to figure out where they wanted their position to be and that they would get back to us.

    And that was around December and, you know, you got to love the holidays and everything else. But so far, no. But we are definitely wanting to also work with everybody with inside WordPress. So we would never want to do anything that Matt or Josepha would think that was not appropriate to the point of wanting us to cease and desist or whatever else.

    And I also know that there’s another company, I don’t know if it’s public knowledge, so I don’t want to just like throw it out there. But there is another company that is building or hoping to build a top tier credential. So it would be like our credentialing, and then you would be able to take theirs.

    And that would allow participants who had that credential to be hired by these absolutely massive corporations that are in WordPress. There are very large companies that use WordPress and they need a certain type of developer and security knowledge. And so that level of credentialing would take it one step above ours.

    And since that company works with those high level companies, they would be the best fit to be able to create that level of credentialing. I mean, that’s the fun thing. The credentialing is coming. It’s been talked about a lot and I’m excited for the growth. I’m excited for the next couple of years to see where these credentials really take us as a community. But yeah, no, so far the conversations we’ve had with, I’ll say the powers that be, have been very positive.

    [00:36:50] Nathan Wrigley: Okay. It’s just nice to hear that you’ve had those conversations because obviously that would be an area of, uh, of concern if you hadn’t, so at least that, that’s been put on the table, shall we say. You mentioned community a few times there, and it might be an interesting moment just to wrap this up to talk about the people that are involved and what have you.

    So, Talisha, there’s obviously you. But you’ve got a whole bunch of other people on board. Do you just want to give us a bit of a name drop on who’s involved so far. And I guess an ancillary question to that is, are you still open for other people to join and lead certain areas, and be involved? Is this still a group which is welcoming community members in to help?

    [00:37:30] Talisha Lewallen: Yes. So right now our advisory board and I always say this like, oh, sorry if I forget anybody. I always feel so bad. Because we have added people on in the last little bit. So we have Courtney Robertson, we have Gabriel Cohen of PMC. Jess Frick from Pressable. Michelle Frechette, love her. And we also have Nikki Bulmer. So they’re both from the Liquid Web brand. And then we have Robbie Adair with OS Training, and we just brought on Zach Stepek, and we brought him on because once we started talking about, okay, we needed the front end and the back end credential. All of us are talking about the front end, and I said, okay, so what do we know about backend?

    What do we know about really coding and what do we know about all of this? And we all just kind of sat there and we’re like, okay, we need to find somebody else that could be that expert in that field. So whenever we find there is a lack of our knowledge, or that we could find somebody that has a little bit more, we are definitely open to bringing them on.

    It’s not that we’re trying to keep it small, but we want to keep the team progressing. And so when you get too many people, sometimes that can be a hindrance to the progression forward, but we also need to have as many people as we need to get the best product possible as well. So we are still open to certain people. If anybody wants to be involved, definitely reach out. If we have the space and need that area of knowledge, definitely want to do that. And then we have our board of directors. And we are trying to keep the board as separate from the advisory board as possible. There are a few people that are crossing over, just because of their expertise and skills whenever we are putting the board together.

    So we have myself, Michelle, Nikki and Jess. But then we also have Rob Howard, and Hans. That is currently our board of directors. We have our first meeting today, actually. I’m very excited about that. And then we have our next advisory board meeting on Thursday, and we are hoping to get the level, so for the front end credential, the level one course and exam approved by the board and the level two course and exam as well. Very exciting stuff happening this week.

    [00:39:50] Nathan Wrigley: Yeah, it’s all moving forward, isn’t it? This is really great. We’re probably just going to have to round it up in terms of time, but before we do that, if people have been listening to this and they’d like to find out more, possibly get involved from either direction, whether that’s from the company side, looking to consume the accreditation, or if somebody would like to be involved in taking the accreditation and wants a little bit more information, where are the best places to go to contact either CertifyWP or just you?

    [00:40:18] Talisha Lewallen: Me, you could find me on Post Status Slack. Or you can always hit the contact forms on either website page. They get emailed to myself to either wpconnects.com or certifywp.com. And we are also in Twitter and we now have Tumblr. We just recently got on Tumblr as well. So any of those ways are perfect ways to get ahold of us. Or my email is always a great way, which is just talisha @ wpconnects.com

    [00:40:46] Nathan Wrigley: As always, I’ll put the links that you mentioned into the show notes, so if anybody wants to follow those up, just head over to the WP Tavern website, search for this episode and you should be able to find the links there. So it only remains for me to thank you Talisha for coming on the podcast today. I really appreciate it.

    [00:41:02] Talisha Lewallen: Well, I very much appreciate you having me and WPConnects and CertifyWP all in one. I know it’s a lot of information, but I very much appreciate it.

    [00:41:11] Nathan Wrigley: Thank you very much indeed.

    On the podcast today we have Talisha Lewallen.

    You might have found your way into WordPress intentionally, or perhaps you stumbled across it and decided to explore further. Whichever it was, you’ve learned things along the way. Some of it might have been through training, but there’s likely been some self-discovery on the way as well. Perhaps you’re a coder, or a designer. In fact, there are dozens of different pathways in the WordPress ecosystem.

    Given the broad range of knowledge you might possess, how can you prove that you know what you know?

    Many industries provide training programs which, when completed successfully, allow you to assert that you are competent in a given area. You’d want your lawyer and surgeon to have passed through the appropriate program of study, so that they’re equipped to do that work.

    With WordPress being such a dominant force in the world of websites, would it be a good idea to have a certification for WordPress? Talisha certainly thinks so and has founded CertifyWP to try to make that happen.

    We approach this subject through the work that she’s been doing at WPConnects in which she’s been trying to provide training to military veterans, so that on their departure from the services, they have the prospect of finding work in the WordPress space.

    We talk about whether there is a need for a certification for WordPress and how such a certification would come about. What levels of training does Talisha see as essential, and how many such layers might there be?

    We discuss whether the WordPress community is ready for a third party to be certifying people’s abilities and whether this strays away from the approach that we’ve had so far, in which routes into employment have relied upon other, less formal, methods.

    Later in the podcast we talk about the structure of CertifyWP and who is behind the project. You’ll hear that it’s not just Talisha, there are quite a few members of the community who want this project to succeed.

    If you’re curious about certifications in the WordPress space, this podcast is for you.

    Useful links.

    WPConnects website

    CertifyWP website

    Talisha on the Do the Woo podcast

    WPConnects Twitter

    WP Connects Tumblr

  • #66 – Sé Reed and Courtney Robertson on How the WP Community Collective Is Helping WordPress Contributors

    Transcript

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, enabling people to contribute to WordPress.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or go to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you all your idea featured on the show. Had to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today, we have Sé Reed and Courtney Robertson, and they’re here to talk about the WP Community Collective, or WPCC for short. In a nutshell, the WPCC is a nonprofit that is hoping to fund contributors to the WordPress project.

    It’s been said before, but I’ll say it again, people who can afford to contribute to the WordPress project are the people who can literally afford to contribute to WordPress.

    This sounds obvious, but think about it for a moment. Most of us know WordPress is built on top of a dedicated base of volunteers. People give up their time and expertise to contribute towards the project, and in this way, make it free to download and use. But we all have to earn money at some point. Most are not in a position to donate their time completely freely. They have to put food on the table.

    Often contributors are sponsored by the companies that they work for, either part-time or full-time. There’s nothing wrong with this model, but what about the capable, willing volunteers who are not in this position? The people who have the skills and motivation to contribute, but not the time or finances to make that a reality.

    The WPCC wants to act as a go-between for companies or organizations who are willing to spend money improving WordPress, and the individuals who can implement those improvements.

    This enterprise will be done via the WPCC fellowships. A fellowship in a specific area of WordPress is created, for example, an accessibility fellowship. People apply for that fellowship, and if successful, get the finances they need to take on the work.

    This means that individuals don’t need to be working for an organization, which funds them directly, and the organizations which wish to contribute don’t need to fund only their own team members.

    We talk about where the WPCC is at with their fellowships, and how it’s set up so that all participants are fully aware of where the money is being invested.

    If you’re from a company who would like to assist contributors to WordPress, or an individual wishing to get involved, this episode is for you.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

    And so without further delay, I bring you Sé Reed and Courtney Robertson.

    I am joined on the podcast today by two wonderful people. I have Sé Reed and Courtney Robertson. Hello, both of you.

    [00:04:21] Sé Reed: Hi. Thanks for having us.

    [00:04:22] Courtney Robertson: Hey, Nathan.

    [00:04:23] Nathan Wrigley: Hello. Hello, hello. Well, welcome. We’re going to get into the meat and the bones of this subject today. We’re going to be talking about the WP Community Collective. I confess at the outset of this episode that I am going to be schooled. Most of the questions that I’m going to ask are from a point of view of ignorance, so forgive me. You’re going to educate me hopefully on this subject and we’ll learn together.

    But first of all, just to orientate the listeners. I wonder if in turn, shall we start with Sé? Just a quick little potted history of who you are and how you’ve come to be in the WordPress space.

    [00:04:56] Sé Reed: I’ve been using and building WordPress websites since 2007, which is wild to me because that’s, I think that’s 15, 16 years. I’ve been doing a WordPress podcast called WP Water Cooler since 2012. That is 10 years. And I have been part of the community, speaking at WordCamps, organizing WordCamps for I think also since 2012.

    I fell in love with WordCamps at WordCamp Phoenix. I live in California, but I went to Phoenix and just absolutely fell in love as people do with the WordPress community mostly. I already loved the software. But yeah, I’ve been part of it ever since. I took a little break to have a kid and then Courtney here brought me right back into the fold. So blame her. It’s her fault.

    [00:05:47] Nathan Wrigley: That seems like a perfect segue. That’s lovely. Thank you. And, let’s then segue to Courtney. Tell us about yourself.

    [00:05:55] Courtney Robertson: Hey there. So I have been in the WordPress community since, well, I started using the software I believe in 2005. It would be around version 2.5. Started contributing by checking guests in at WordCamp Mid-Atlantic in 2009, and joined the training team, thus beginning my actual team contributions. In 2014 have had several stints of being the training team co rep. And at this time, you could still find me within the training team as a WordPress faculty member. And when I’m not doing all of those wonderful things, I am a developer advocate at GoDaddy Pro, and a lot of that work involves working with the open source and specifically WordPress communities.

    [00:06:42] Nathan Wrigley: Wow. Really deep and rich, both of you.

    [00:06:44] Sé Reed: I forgot to say what I do, now. It’s all about the past. I was like, oh yeah, the present

    [00:06:49] Nathan Wrigley: Well tell us.

    [00:06:50] Sé Reed: Courtney reminded me with her awesome contribution. I just took on a co-team rep role as well on the make marketing team, for 2023. So that’s exciting. In my day job I have my own company and I build websites for people and do digital strategy of all kinds.

    [00:07:09] Nathan Wrigley: I’m often in awe about how many different roles there are in the WordPress community. I remember when I first stumbled across the software, I just viewed it as exactly that. It was a piece of software. So this is going back probably to 20, I don’t know, 2014, 2015, something like that.

    And then it very quickly became apparent that there was an awful lot going on with the community. Much more than I’d anticipated. And fast forward to today, 2023. I mean it has more or less taken over my, my entire life. It is more or less everything that I do.

    [00:07:38] Sé Reed: We can relate to that.

    [00:07:40] Nathan Wrigley: Right. Yes. So we’re all in good company. We’ve given ourselves up to WordPress.

    [00:07:44] Sé Reed: To an ethos, I think, is really what it is. I think that’s part of what draws the community together. You didn’t ask, but I’m going to answer it anyway. I think that’s really what, that ethos and the being part of something bigger. Whether it’s open source or the community or just spreading the goodness of easy to use software. I really think that’s what makes it different.

    [00:08:05] Nathan Wrigley: Yeah. Somebody was saying to me the other day about their conversations that they’ve been having with people about ceasing to use WordPress as their CMS of choice. But the glue which has kept them in it is the community. It’s that piece which has actually kept them going with the software. So in a strange sense the community has trumped the software in that instance.

    [00:08:28] Sé Reed: That’s so true. I think that a lot of people stay in WordPress and WordPress has had such a, well, 20 years, this is its 20th anniversary year. So it’s had that success. I truly believe because of the community and because of the, really the stewardship that’s happened within the community. And again that ethos of drawing people together and, really just feeling like there’s a sense of, sort of a sense of ownership I think over, or at least stake in the community and stake in the software. It feels like we all have a part of it. I think that that’s, it’s something really special. It doesn’t exist even in other open source communities to the same degree.

    [00:09:10] Nathan Wrigley: Yeah, it is constantly remarkable to me that that is such an important piece, and it’s so ephemeral. I can’t quite get my hands on it. I don’t really understand what that thing is, but there is a thing there.

    [00:09:21] Sé Reed: Exactly.

    [00:09:22] Nathan Wrigley: And, it’s wonderful and it, it’s gathered us together today to have a chat. You’ve recently got involved with something that, I’m going to pronounce it once. I’m going to say it once at the beginning and then I’m going to truncate it. So from the start we’re going to be talking about the WP Community Collective, so the WordPress Community Collective. But I’m probably either going to call it the community collective or just collective, because it’s going to be a whole lot easier.

    [00:09:44] Sé Reed: Yeah. I didn’t think about WPCC being hard to say in a British accent, but.

    [00:09:48] Nathan Wrigley: No, it’s funny, isn’t it? But that acronym somehow completely gets stuck on the end of my tongue before it escapes my mouth. What is it? I don’t mind which of you want to take it on? What is it? How did it come about? Broadly, in broad brush strokes, and then we can get into the detail. What’s the point of this?

    [00:10:04] Sé Reed: What’s the point? That’s a great question, Nathan. I’ll take it, just to give the broad strokes. What the WP Community Collective is, is essentially it’s a non-profit project that allows, we are in the process of funding contributors to the WordPress project. So people who are working on the make teams and the open source WordPress software, that’s who we’re going to be, who we are supporting.

    And, it’s really a way to bring together the community to allow us to fund and support the contributors who are doing so much work to keep this software slash community slash lifestyle going, moving forward and growing and responding to the needs of the community and technology. So really it’s about supporting the contributors that make up the community.

    [00:11:06] Nathan Wrigley: So you mentioned two things there. You mentioned funding, and obviously that’s a key component of it, but you also mentioned more the community side of things. Being there as a supportive hand. Are they two distinct parts or is it all about the funding? Is that primarily what it’s about, or is it also about being a friendly face?

    [00:11:25] Sé Reed: We’re trying not to be, we are, and we’ll continue to try to not be US focused. That’s something that happens a lot. That kind of defaults to that when we’re here. But, in America, the way that we like to show our support is with money.

    That’s a thing. You know we tip people. That’s sort of how we demonstrate that we like a thing. So not trying to bring that ethos necessarily into the greater world, but primarily we mean funding. So primarily we mean sponsoring people to do contribution of various types.

    But we also have goals to basically be like a third space to have conversations about WordPress and the WordPress community and the ecosystem adjacent to the WordPress project. So, you know, all of the plug-ins and the themes and the assemblers and all of that world, the marketers. So, we want to provide a space to integrate all of that. But that’s more of just soft support. Really what it does come down to is funding support.

    [00:12:36] Nathan Wrigley: Okay. Given that you’ve set up this WP Community Collective, and usually when something like this is set up, there’s a problem to be solved. There’s something that is identified as could be better. Let’s all gather around and figure out how we can do it. So, essentially what is the problem around the community?

    What are the problems that people are facing? Is it one simply that people who would willingly contribute their time simply can’t afford to do it? We often hear this mentioned that, you know, those who can afford to contribute are the ones who can afford to contribute, because they live in a certain part of the world. They may be fully employed so they can dedicate something. Perhaps their company is kind enough to, give them a day, a week or half a day, whatever it may be. They’re seconded in some way so they can contribute to the project. But there’s a whole ton of people, hundreds of people who would love to be in that position. But the financial component is the barrier. It’s the wall that’s stopping them being able to contribute.

    [00:13:33] Sé Reed: Yeah, at the end of the day there’s really two sides of this. And, one side is how can people effectively and consistently and meaningfully participate in the project if they can’t consistently show up? You know, so much happens every day in the WordPress make channels on the P2s, on the blogs. There’s a lot going on, and there are a lot of people moving the project forward and even just paying attention and keeping tabs on all of the new stuff that’s happening is kind of a full-time job.

    So really, what ends up happening is that the folks who are in leadership roles tend to be sponsored contributors. And I say leadership roles, whether that’s a team rep role, which is, it’s leadership, but it’s not like authority leadership. But, just by showing up consistently and responding to things and being there every day, which you can do if you are paid to do so, that gives you, I don’t want to use the word clout, but it gives you, I’m not really sure what the word is. When we talk about it being a meritocracy, right?

    If you do things, then you have influence, and people want to do more, but only the people who are really supported financially to be able to do that. Or like you said, have the means in some other way, have the ability to consistently show up in that meritocracy. And so in a way, by default, we’re really the leadership and the ongoing constant push forward really does tend to be from the sponsored side of the contributor pool, let’s say. And everyone else tends to just be catching up or lending their opinion in different places.

    So, that’s one of the reasons, is we want to be able to have folks contribute and contribute consistently, and contribute in a meaningful way to parts of the project that are maybe not getting as much of attention or need more attention, like accessibility. And so we’re really trying to find a way to support those people, and bring the community together to support those people. And really, Courtney can talk a little bit about the problems that, it’s not just that individuals have problems finding support, it’s that the people who want to support have problems funding the individuals. So Courtney, do you want to talk to that, about that a little bit?

    [00:16:05] Courtney Robertson: So for context, I shared that I had started contributing in 2009, and for a number of years, in fact, up until a year and a half ago, I was not sponsored. I wouldn’t even say I was self sponsored financially. But I contributed. In fact, I was the person couch surfing at a WordCamp US on my college roommate’s couch, and driving quite a distance in, and could, at the time, barely scrape together the funds to take care of my parking.

    So I know what that experience has been like and to still want to contribute and to still feel that this is part of my work, my role. And I undoubtedly benefited from all of the hardships of my past. I’ve had some medical challenges, some other life things, you know, as people do. And without that experience, I certainly wouldn’t be involved in WPCC. I wouldn’t have gotten to the job that I have now at GoDaddy Pro. There’s just a lot of reasons for seeing from that perspective that I think has really benefited.

    So from the person that is seeking to be sponsored in some capacity, I’ll say what I did, very publicly. I was teaching at the time, I loved it, but I felt like my higher purpose was to do more of the work on Learn to be able to create this content that could be a multiplier effect to impact that many more students, that many more learners than the current job that I had had.

    And in order to do that, I started to let some folks know. And I went to my now manager and said, if GoDaddy ever has a role open up where I could be contributing to the training team as part of my work time, Adam Warner, please keep me in mind for that. And in fact, he did. Now, that doesn’t mean that everybody has the gumption to go out and start approaching folks and say, I would like to receive.

    I appreciate those that have spoken up and let folks like Sé and I know. We’re working on some processes to sort of collect that information. Who’s already contributing that would like to contribute at a higher capacity? We have some contributors that I know of in our WordPress community that said, I would like to be sponsored. For instance, Joe Dolson says, I would like to be sponsored at $500 US a month to contribute this certain amount to accessibility purposes. Other than that, I’m tied up with clients. And then increasingly grew that over time.

    But still that process, it doesn’t matter who you are or where you’re from. That process of saying, I want to do this takes a certain amount of navigating, what can be perceived as awkward because you’re expecting handouts, but at the same time you are a professional and you bring professional caliber qualities to the work that you do for this open source project that is used by 43% of the internet.

    So yes, there is a reason that contributors should be funded. We definitely know this and that pathway of letting folks know can be awkward and challenging. And then the pathway from those that have the funds to do the sponsoring, whether you are an individual or a company, both perspectives of this get a little tricky.

    So from an individual’s perspective, there are those if you look through the WPCCs sponsors so far, we’ve raised all of our funds essentially through individuals at this time. And that’s several thousand US dollars. So that’s just coming in from individuals who said, yes, this matters. Yes, we want to fund what’s going on in the work.

    And so it takes a lot of people, that are individual people, giving a little bit to reach that kind of a goal. And then from a company’s perspective, a lot of companies struggle too, how to fund the work of open source. And recently I’ve been researching in and getting into this more deeply, and it’s not just about the WordPress community, but just how does whether you are an individual, small business company, and I see some really great ones that are doing this.

    JB over in the Core team is part of about a two dozen staff member agency based out of France. And all of their staff are contributors. And I think it’s amazing that companies who done it. So, great work on them. But other organizations, whether you’re a small business, you may not quite know how, well, how do I manage, how do I, if I’m contributing, what do I get? Is it just I’m contributing in a charitable way and I don’t have much attachment to the work that the person does? How do I know that what I’m contributing to has any payoff for, not just the goodwill of my company, right? That’s a marketing approach, but also that the people receiving it are actually doing something productive with it.

    Should there be accountability in all of that? When you get into larger size organizations like my employer, we’re not structured in a way, we’re a publicly held company. We’re not structured in a way that has a whole staff of who’s overseeing the work of those that we are sponsoring.

    GoDaddy does have two full-time people that are essentially staff that we sponsor to work on WordPress. We ambitiously would like to keep growing that, but there are challenges. So when it comes to GoDaddy related to WPCC, I’m really excited that we’re in the conversations right now of getting that money flowing a bit more.

    I can’t make any promises from GoDaddy’s side of as to what all that would look like, but what I can absolutely say is that we know it’s a real need. We know that the WordPress community will greatly benefit from this. But as it would turn out, a large company like this can’t just go making purchases from any kind of business or giving money to any kind of organization.

    [00:21:27] Sé Reed: Shareholders don’t like it when you just randomly give money to people.

    [00:21:30] Courtney Robertson: No, they don’t.

    [00:21:32] Sé Reed: They don’t.

    [00:21:32] Courtney Robertson: Oh, there are so many stories that I could say. But, to that end, what I for sure am happy to say though is that we’re working together in a way that will do all of the red tape that a company would need, to get that approved and cleared so that those funds can start flowing. And, so I’m really excited about it from that side because you know what? GoDaddy can’t just stuff a bunch of bills in an envelope and mail it out to someone. They have to actually have a strategy when it comes down to why are we doing this? What’s the outcome? What’s the, the ROI, right, of these things?

    And investing in the software that powers 43% of the internet, that many of our customers are using. Well that sounds like we have a good reason to be investing in that. So it makes it quite interesting to navigate those challenges. From an internal perspective, I encourage folks at other corporations, if you’re facing those challenges, to reach out to me and I’d be happy to have some private conversations with you about what specific challenges you might be facing.

    [00:22:34] Sé Reed: And how the WPCC.

    [00:22:36] Courtney Robertson: Yes, can help with that.

    [00:22:38] Nathan Wrigley: Courtney, there was loads in there, and I just want to drill down a little bit on you personally, if you don’t mind, because I find that quite an interesting dialogue. You used the word gumption there, which I thought was quite interesting. And, it sounds like you’re very self-reliant. You are driven, and it sounds like you just kept banging on doors and fighting the good fight and keeping going, and eventually that paid off. But I’m guessing that there were times during the period where it wasn’t paying off, where you must have looked at yourself and thought, what the heck am I doing?

    And I guess that’s the person that is going to benefit from this, the person who knows that they want to contribute, but really has maybe been trying, struggling, doesn’t have a way through, doesn’t have a pathway through. And we don’t want those people to be disappointed and turned away.

    [00:23:22] Courtney Robertson: Correct. Yeah, so for a number of years, in fact I took a hiatus. I had little kids and I had a set amount of hours available in my day, and I worked for a WordPress plugin company that I loved that experience. But I worked during only their nap time schedule. So, I didn’t have time to contribute or even keep up with the quantity of information that was happening on WordPress. And that was all during the lead up to and release of Gutenberg. So, it was a hard time to be missing all of that information.

    But I will say that there are a wealth of contributors in our community that if they had that financial backing would have a better quality of life, be able to contribute that much more because they could let go of their other income sources as an offset.

    So I had started to let the previous employers, I worked for two other WordPress organizations previously, and I started to let them know that I would like to be involved more in WordPress, and the work happening there. And they didn’t have that capacity built into their business models, right. And so I felt that by approaching somebody like GoDaddy, I knew that they had a couple of contributors, and this was more of a, the role that I am in affords me some time. I am not full-time sponsored to WordPress. But it affords me quite a bit of time and it is vital to the job that I do to be a contributor, if that makes sense?

    [00:24:53] Nathan Wrigley: Yeah. That’s really, really interesting.

    [00:24:55] Sé Reed: I was going to say that that’s the, it’s exactly that dilemma that even Courtney, who is literally representing open source and doing massive WordPress contribution with her company. Even her job is not a hundred percent WordPress. And that’s part of it because there’s a need for contribution.

    I don’t know, we really have clarified that part, but like the contribution has, because of covid, because of the lack of WordCamps or whatnot, did definitely take a dive. And also there are so many other CMSs and worlds out there that it’s not just inevitable that WordPress is going to continue to have a healthy community and continue to grow and continue to be the CMS and the software that we all know and love.

    That’s not a given in the world of actual capitalism that we live in and whatnot. So if we want it to be around, if we want to support it, then we need to find ways to connect the resources that are there with the efforts that can be made on the ground. And making that connection between companies that have budgets, but don’t have the ability to hire people. That is really, I think the, well, it’s not just for companies, but that’s really the key element for the WPCC.

    Because we know there are lots of resources out there. There’s lots of agencies, there’s lots of businesses that have some funds, you know, they’re making revenue off of their various products or their services. But they can’t say maybe giving five hours a month or something isn’t even that productive for them. But if they were able to take their money and combine that with other folks who are also in the same situation, then they can help fund someone who is able to put that focus in.

    And also a big part of what we’re doing is making sure that those fellows are talking about what it is they’re doing. The challenges that they’re facing. So bringing the information also back out into the community, so it’s not just a you’re putting money in and you know, you never know what happens to that, right?

    Our fellows will be responding, or blogging actually, on the website telling us what they’re doing. Telling us what’s going on in the project and, so folks who are putting their funds into the WPCC are combining their money to make it more effective, but also doing it in a way that gives them a say in it. Not necessarily a say in it, but like a part of it. They get to participate in it.

    They are also part of the community collective. So it is all, all of us working together. So it’s really just about allocating resources and, available energy really. We’re just putting resources and energy together and combining them and helping to move the project forward.

    [00:27:56] Nathan Wrigley: Yeah, so essentially it feels to me, I mean I may be parsing this wrong, but it feels like you are acting as a conduit. You are the bridge between the people who have money, let’s say for want of a better word, finances. But they don’t necessarily know where those finances would best go. So they come to you, deposit it there in the collective, and then your job is to make decisions about who would be the best steward of that money.

    And then get them to do whatever it is that you’ve agreed to do and then report back to the sponsors in the form of blogging or what have you, so that they’ve got some way of, well, I guess the word is, sort of oversight really. They’ve got a little bit of oversight and they can see that their money hasn’t in fact just been squandered. And so it’s a really neat little idea.

    [00:28:45] Sé Reed: Thanks, we like it.

    [00:28:47] Nathan Wrigley: Yeah, yeah. The thing that interests me is, as soon as you get involved with money, and you alluded to this earlier, you know. The government, they don’t like to have people just willy nilly spraying money all over the place. And so if companies are giving you money, presumably they want to know that it’s being marshaled correctly, you know. It’s not being squandered. It’s being used effectively in ways that perhaps align with a brand that they’ve got, you know, it maybe that they want it to go in a particular direction. They might be more interested in accessibility than others. Others might be more into, I don’t know, we could invent a thousand different other categories. How does that all get figured out? In other words what are the kind of roles that you are giving people who are taking on the work that you are paying them for?

    [00:29:30] Sé Reed: That’s a great question. We are starting with accessibility, because it is so clearly a need, and it is also very, very underfunded in terms of sponsored contributors. We’ll be launching, I keep pushing the date on this, but we’re going to be launching our first, or announcing who our first fellow is shortly, for our accessibility fellowship. The goal is to fund that person for five hours a week for a minimum of six months.

    Normally we would fund the entire fellowship prior to launching it, or starting with the person. We would fund the fellowship first. But in this case, we wanted to start with a fellowship that we already knew was really important. And so we created the accessibility fellowship first.

    That’s really our initial goal is to get that funded. So we are working with some additional partners to develop partnership fellowships. And essentially those, it’s in a way, it’s like a scholarship, right? A fellowship is very much like a scholarship. We’ll have an application process for folks to apply to be fellows, and then different fellowships will have different focuses. So we are scoping out currently, like I said, accessibility fellowships, but also some Core fellowships. And not just Core in terms of development, but also Core in terms of communication.

    [00:30:51] Courtney Robertson: I’d like to elaborate a little bit on what Sé was saying there is that, as part of all of this, we have so many roles across different teams. Whether you are in Core because you’re a developer or because you can help wrangle the information that the Core team needs to function as a team, to share externally.

    Over in other teams we need some assets like project management. In other teams, we need areas like project management skills. Accessibility could relate to the accessibility of the software, but it could just as easily relate to the accessibility of the learn.wordpress.org content, and or site functionality. So you could see how there are different roles beyond what we normally envision for the different teams that relate to just keeping the whole project up and running. And we’re pretty aware of that.

    Likewise, being able to get to your nearest international camp and or a couple of very local regional camps might be important. Or ongoing professional development in your areas. So those are all skills and assets and resources that come to our mind because we have been both contributors into the WordPress project for quite a while.

    Additionally, if I were to ask folks how to get involved in the WPCC, there are a few ways to do so. Any person is welcome to come be a member. So we have memberships available, anyone can be a member. Ideally that would come with a few funds towards those that are contributors. But we welcome members to just come and join. And the show notes will link you over to our website, and from there you can follow it out to the opencollective.com/thewpcc.

    We also welcome sponsorships. Sponsorships, again would look like those that would like to sponsor a specific initiative. So if we have a very specific fellowship that you would like to help fund, you can choose to come along and be a part of that.

    And then we also have areas for partnerships. And that’s the area that, one of the areas that, my employer is starting to look at is partnerships. So perhaps they would like to kick off a specific fellowship, right? There might be general fellowships that the WPCC declares and says, the WPCC needs to, sees that we need to work on accessibility. So we’re going to launch one of those.

    But what if there were specific fellowships available based upon different companies in the industry, right? And so if you would like to set up a specific partnership to drive a specific initiative, that’s definitely an option available as well That could also look like partnering with other WordPress organizations to help fund initiatives that we’ve seen already.

    I loved for WordCamp US the amount of organizations that pulled resources together to increase diverse speakers at organizations. To increase diverse speakers to attend and speak at WordCamp US. So we can partner with lots of different organizations. We hope to be announcing some of those partnerships in the not too distant future to really benefit what the work of the WordPress community is and what that can look like.

    [00:33:56] Nathan Wrigley: So the next question I’ve got is, Courtney just then mentioned that happy to have people come along and if they bring finance with them, that’s very, very welcome. But let’s say that I come along and it’s my company, or it’s me and we just bring a modest amount of money. You know, I’m not a giant entity. I’ve got $500, a thousand dollars, whatever it may be. Do I have sort of any say in where that ends up? Or is it more a case of just trust us on this one? We’ll publish some documentation about where the money’s being spent? Where do we stand with that?

    [00:34:30] Sé Reed: Well, the organization that we are fiscally hosted through, is a, it’s a payment system essentially, with nonprofit sponsorship that allows us to take in funds and spend funds and the entire budget, every dollar that goes in or out of the WPCC is documented and on the website for everyone to see. So everyone can see exactly where all of the money is going in terms of accountability.

    But in terms of participatory, or just influence or whatnot. We’re actually in the process of working on our bylaws, but our rough outline for this is essentially that we have a membership and you can join for free, or you can join at a membership payment level annually, if you want to support that way.

    And we’re working out the exact guidelines for voting and that sort of a thing. We want to base it on, have you contributed in the last year, or we’re working on those types of criteria. But essentially the membership will be able to, first of all talk to us, which is not just talk to us, but talk to the board. But we’ll also be part of the decision making process. Not on a individual, specific, fellowship level, but on a what do we focus on level.

    And also for the larger projects that we want to take on, the community will be, or the membership will be involved in that as well. So, a company cannot be a member because we don’t believe in Citizens United in our organization, which is a Supreme Court ruling that said corporations are people here in the US. So it’s only individuals who are going to be able to participate as members.

    Like I said, that will be more of a let’s figure out what needs to be funded. Do we want to worry about old bugs in the system, or do we want to fund accessibility, or do we want to really have a push to the re-envisioning of the media manager, for example. The media library. So, the community, the membership will have a say in that type of way. It won’t be that the community, the membership is voting on every single action that is taken. Because that would become a bureaucratic nightmare.

    But in terms of direction and goals and partnerships and strategy, the membership can and will be an active part of that conversation. So our goal is to really be transparent and also be a, sort of a incubator for those conversations about funding. About project priorities that aren’t just the make project priorities. Because there are also important components that affect the rest of the ecosystem, like PHP 8, for example. And the push, the development push, that’s needed to get things ready for that. Like that’s something that’s definitely been important to the community, but has not necessarily gotten as much traction in Core as some people would like. So there’s all sorts of different issues like that that can be given attention and brought to the surface, and hopefully, we all just can move forward, move the project forward, more.

    [00:37:47] Nathan Wrigley: Can I ask in terms of the fellowships and who receives the fellowships? So how will that work? So let’s say, for example, I would like to contribute my time into some area, and I notice on the website at the time that I’m looking that I fit the bill. I would like to help in that way. Is it kind of like a job application process, where I fill out a form and some panel that I may be speaking to, or may do it without the need for my attendance.

    Do they decide who it’s going to be? Because obviously there’s concerns there about things like favoritism, or whether the correct person gets the job. But also concerns about weighting things so that people who perhaps, how to describe this, people who currently really would struggle to be able to contribute, maybe they get some leg up if you like. There’s a little bit more weight for certain individuals than others for the circumstances in which they find themselves. So just questions around that really.

    [00:38:44] Sé Reed: It’s going to be more like, rather than a job application, more like a scholarship. And that’s really what fellowships, that that kind of fellowship structure is really why we chose that. Because, it’s not a permanent position. It’s a temporary position, six months, a year, two years, depending on what we, you know, are tackling. Maybe even three months for short term contribution if that needs to happen.

    But, basically it’ll be, we will create the fellowships and identify the need, and then open applications for people to apply for the fellowship. And then we will evaluate those applications and select fellows. So essentially it’s very much like a scholarship or, I would like to think less like a job interview.

    [00:39:26] Nathan Wrigley: So given everything that Sé just said about the way that you are going to be giving out these fellowships, and the way that they’re going to be distributed. Given that there’s a lot of work on the sponsorship side, there’s a lot of work on the people who are getting these fellowships as well.

    There must be a lot of work being done by you and the people in the organization. So how is that funded? Is there a certain proportion of the finance that goes through the WPCC that is taken for administrative tasks and so on? Or is this an entirely nonprofit? I think in the US you call it a 501C3?

    [00:40:04] Courtney Robertson: Yeah, so there are a few ways of the funds coming in. It is an option, strong option to go through the nonprofit direction. There is a total of 15% overhead that we need to take care of. Some of that goes to the direct operating costs of the WPCC. And to be clear, that doesn’t fund Sé, Katie or I, who are the current board members, personally. That just goes to the operating expenses of the WPCC.

    Also, there is a fee in addition to that, that goes through Open Collective because they are the payment processor. They are the way that makes it possible for us to see all of these financial transactions. This is an organization that is set up specifically for open source initiatives, and they provide that oversight. That means we don’t have to go get a bank account. We don’t have to go set up a non-profit organization. We don’t have to do all of those extra things because Open Collective provides that for us and many others. So they do take a small portion of the funds that come through.

    And the remaining amount goes directly to those that are doing the work. At this time, because we are the three that stepped in together and said, let’s launch this thing, we are the board. Over the next year you’ll start receiving some more announcements and information about putting together a more complete board. That board will always hold a seat for the executive director of the project, whomever that shall be. So that’s definitely going to be one board member, optionally, additionally added.

    But in addition to that, we will be looking for those to become board members over the next several years. This first year out, we just thought, you know, we just need to launch this thing and get some traction going. Let’s get some action happening.

    [00:41:53] Nathan Wrigley: Yeah. This may sound like an incredibly cynical question, and I apologize if it is. Sometimes I get the feeling that companies when they do sponsorships and things like that, they like to proclaim, they like to advertise the fact because it’s good business. You know, they’ve done a good thing and they would like a little bit of recognition on the backside of that.

    Is there anything in here like that for people who contribute? Say, for example, a company, they might get a badge or a sticker or some kind of way that they can say, look, in the year 2020, I contributed to this project and I’m proudly going to identify myself as such.

    [00:42:30] Courtney Robertson: Sure. So first and foremost I’ll speak to, there are three different departments within my employer at GoDaddy, that each have varying reasons they would like to make use of funding contributors through the WPCC. Out of all of those, none of them are for self-interest. And I say this to be super clear to the community, yes, I am an employee. Yes, I have mentioned my employer many times in this episode. But it really is not about proclaiming, here we are, look at us.

    I do though understand that there is a marketing advantage and so, I think it is worth people being aware of the good that does happen. That’s not the sole reason why it should be done, this work should continue. But for those to know who is helping make that work be possible, the WPCC will be able to set up fellowships with those partnership type of programs, those partnership initiatives, so that if some other organization would like to come along and say, we would like to start up a fellowship for an individual or for a group of individuals, and that being maybe a six month rotation.

    And out of that, perhaps they later bring them on as staff as well. And so there is that piece, or that component as well, where the WPCC can be that entry point. Especially for organizations that don’t have the dedicated internals of managing and maintaining this. And they’re just beginning to explore what does it look like. Or they would like the contributors that are doing this as their job to be really thoroughly trained.

    And also, all organizations that sponsor contributors, some of that information goes back to what that company does. For instance, I know that the work that George Mamadashvili does in Gutenberg really helps shape some of the internal information around how some of the themes and plugins that GoDaddy creates makes Gutenberg implementation possible for our customers, right?

    And so, there’s a lot of value in this, and at no point would I ever slight that a company should be able to say, here is what we have contributed. Especially when many are looking at or watching, well, how do you contribute to WordPress as an organization, right? So those fellowships and the partnership programs will definitely be an option for that. As well, organizations can say, we are providing this amount of funding, and it could go into whatever bucket the WPCC would like to put it into.

    [00:44:58] Nathan Wrigley: Hmm. I guess you’re on the first few steps of hopefully a long journey and a lot of these things are going to be ironed out and figured out over time.

    [00:45:07] Courtney Robertson: Right.

    [00:45:08] Nathan Wrigley: Courtney and Sé if somebody has been interested in what they’ve heard today and they would like to come to you and get some more information, where is the best place to find you? Let’s start with Courtney.

    [00:45:20] Courtney Robertson: You could find me personally as courtneyr_dev on most of the social platforms. Sometimes that’s a hyphen. If you get lost, head to my personal website, courtneyr.dev. You could certainly find out about thewpcommunitycollective.com. That will get you the information that will take you across our website as well as across to the listing that we have with Open Collective, where you can actually put in your information.

    [00:45:47] Nathan Wrigley: Thank you very much. Right, Sé. Where do we find information about you?

    [00:45:51] Sé Reed: Well, the best thing to do is go join us on the thewpcommunitycollective.com. Connect to us by joining our organization. That’s the best way. But I am currently @sereed on mastodon.social. I’m on LinkedIn. I’m in the Slack channels. I’m in the Post Status channels. So if anyone wants to get a hold of me, probably Slack in the WordPress community is the best way. I still look at my Twitter DMs, even though I’m staunchly anti Twitter now, sadly. But I’m still there. I’m still around listening, so. I’m at sereedmedia on all the things, I’m around. There’s, I don’t know if there’s any other Sé Reeds either, but you know.

    We really want to participate with the community. We really want to hear from the community. Have ideas, have suggestions, have comments. This is a community effort. This is a, a larger project than Courtney and myself. We’re trying to be anti gatekeepers. Taking influence from Courtney, who is an anti gatekeeper. We really want this to be a community project and a community organization. So please get involved. Connect with us. We want to hear from you.

    [00:47:02] Nathan Wrigley: I will make to put all of the links in the show notes, so if anybody is curious, just head over to wptavern.com and search for this episode. Really an absolute pleasure talking to you. I’ve learned a lot. I’ve definitely got a much greater, more concrete understanding of exactly what the WPCC is, and hopefully you will get some more interest as a result of this podcast.

    Courtney, Sé, thank you so much for joining me today. I really appreciate it.

    [00:47:27] Courtney Robertson: Thank you Nathan.

    [00:47:28] Sé Reed: Thank you Nathan.

    On the podcast today, we have Sé Reed and Courtney Robertson, and they’re here to talk about the WP Community Collective, or WPCC for short.

    In a nutshell, the WPCC is a non-profit that is hoping to fund contributors to the WordPress project. It’s been said before, but I’ll say it again, people who can afford to contribute to the WordPress project are the people who can literally afford to contribute to WordPress. This sounds obvious, but think about it for a minute.

    Most of us know WordPress is built on top of a dedicated base of volunteers. People give up their time and expertise to contribute towards the project, and in this way make it free to download and use. But we all have to earn money at some point. Most are not in a position to donate their time completely freely; they have to put food on the table.

    Often contributors are sponsored by the companies that they work for, either part time or full time. There’s nothing wrong with this model, but what about the capable, willing volunteers who are not in this position? The people who have the skills and motivation to contribute, but not the time or finances to make that a reality.

    The WPCC wants to act as a go between for companies or organisations who are willing to spend money improving WordPress, and the individuals who can implement those improvements.

    This enterprise will be done via the WPCC fellowships. A fellowship in a specific area of WordPress is created, for example, an accessibility fellowship. People apply for that fellowship, and if successful, get the finances they need to take on the work.

    This means that individuals don’t need to be working for an organisation which funds them directly, and the organisations which wish to contribute don’t need to fund only their own team members.

    We talk about where the WPCC is at with their fellowships, and how it’s set up so that all participants are fully aware of where the money is being invested.

    If you’re from a company who would like to assist contributors to WordPress, or an individual wishing to get involved, this episode is for you.

    Useful links.

    WP Community Collective (WPCC) website

    WP Watercooler podcast

    WordCamp Phoenix

    WordCamp Mid-Atlantic

    GoDaddy Pro

    Make Marketing Team

    Learn WordPress website

    WPCC on the Open Collective website

    Open Collective website

    courtneyr.dev – Courtney’s website

    Courtney’s Twitter

    Sé’s Twitter