#126 – Aaron Jorbin on Navigating WordPress Major and Minor Releases

[00:00:19] 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 WordPress gets updated.

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/feed/podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature in the podcast while I’m keen to hear from you and hopefully get you, or your idea featured on the show. Head to wptavern.com/contact/jukebox .

And use the form there.

So on the podcast today, we have Aaron Jorbin. Aaron has led teams responsible for some of the largest and most prominent WordPress sites in the world, including Rolling Stone, Variety, WIRED, The New Yorker and The White House. He’s also a WordPress Core committer who focuses on improving developer happiness, and making the internet usable by everyone.

He’s been an integral part of the WordPress community since 2010, and today Aaron opens up about the crucial importance of major and minor WordPress releases, and the need for user trust, which forms the backbone for features like auto updates that enhanced WordPress security.

We get into the process behind WordPress releases, discussing how major and minor releases a planned and executed. Aaron explains the dynamics of the Core Committer community, a group of around a hundred dedicated individuals, about 50 of whom are currently active, whose decisions and hard work keep WordPress robust up to date and secure. The commitment to transparency, minimal egos, and the ability to handle criticism are mentioned as key elements for maintaining trust inside this community within a community.

We talk about how communication and decision-making take place mostly in public forums, ensuring openness and collaboration. The conversation also touches on the ebb and flow of volunteer and sponsored contributors. The challenges of coordinating across global time zones, and the need for asynchronous decision-making.

Aaron explains what it takes to move from a small contributor to a key player in the WordPress ecosystem, emphasizing the burden of responsibility that comes with making changes affecting millions of non-technical users. Whether you’re a developer tester or enthusiastic user, Aaron encourages contributions in various forms, from sharing ideas to testing and providing feedback.

If you’ve ever wondered how WordPress is maintained and updated, 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/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Aaron Jorbin.

I am joined on the podcast today by Aaron Jorbin. Hello Aaron.

[00:03:42] Aaron Jorbin: Hello Nathan.

[00:03:43] Nathan Wrigley: This is going to be a really interesting episode, and I confess, dear listener, that this is an episode that I basically know almost nothing about. So everything that comes out of Aaron’s mouth is going to be schooling me in a process that I know nothing about.

But it is probably the most important process. Without the process that we’re going to discuss today, the entire enterprise of WordPress doesn’t exist, because we’re going to be talking about the way that WordPress is released, goes from one version to another.

Before we get into the meat of the podcast though, Aaron, can I just offer you the opportunity to tell us a little bit about yourself, who you are, where you come from, where you are at the moment, because that’s kind of interesting, and what your role in the WordPress community is, please.

[00:04:26] Aaron Jorbin: So I am Aaron Jorbin. I have been a Core contributor since 2010, and have been involved in WordPress since about a year or two before that. I went to a WordPress meetup and got sucked into the community, got lucky. And it was right before WordCamp Portland 2009, which was sold out in like three hours. And so I had not gotten a ticket, and there was a raffle for tickets. And so I was able to win the raffle and get a ticket, and get to go to a WordCamp, and start meeting the people that I had known from IRC in real life, and got brought in then.

And my role, I am one of the Core committers, so I’m one of the one hundred or so people that can make changes to WordPress Core itself. And for the last year, I’ve been specifically focusing on the minor releases of WordPress, so the maintenance and security releases.

And these are ones that are much smaller in scope, these aren’t bringing in new features, but in my opinion, some of the more important ones. They’re the ones that are auto updated by default.

And so the changes that we make in these releases go to every site. And it is a terrifying moment when you start rolling them out, and you just have to cross your fingers that everything is going to go smooth. And so we’ve put a lot of processes in place to help them go as smooth as they possibly can.

That has been my main focus, but I’ve also worked a lot on the build tools of WordPress, and on the more low down systems. I haven’t done a lot with many user facing features. I think the last user facing feature that I had a heavy hand in was the ability to log out of other, where you were logged in elsewhere. And we did user testing for that at the final WordCamp San Francisco, so I think that was 2014.

[00:06:29] Nathan Wrigley: Honestly, what a fascinating story. Can I just ask though, if we go back to 2010, I think that was the year that you said you began your WordPress journey. So it’s a long time, you’ve been doing this software now for 14 years. What was the path of escalation that took you from, I’m brand new to WordPress, to Core Committer?

Because it feels like, if you’re into the software of WordPress, Core Committer is, that’s like where the road ends. There’s not really too many places to go beyond there. You know, you’ve got the capacity to improve WordPress. You could destroy it if you so wish to. So how did that path happen? And I’m guessing it was a sort of slow, incremental community journey, but I’d love to hear that.

[00:07:07] Aaron Jorbin: Yeah, so my first code contribution was, so Jen Milo, who was at the time the UX lead of WordPress. She published a blog post about a few small UX changes she would like to see in WordPress Core. And I was like, well, I’ve got some extra time on my hands. I’m going to try to work on one of these.

And I sat down for a couple of days, and worked on the initial patch for it, and went back and forth with Andrew Nacin, who was a new committer at that time, and we came up with a solution. This was during the 3.0 cycle, and it was for the ability for you to see, if you attempted to change the admin email in WordPress, it sends an email that you need to confirm, but there was no notice whatsoever that there was a pending change. So it was just adding a notice that there was a pending change, so you could know that someone had tried to change it.

And so, worked on that, and that got accepted. I was very excited. I ran home to my then girlfriend, and told her, oh my God, oh my God, you’re not going to understand any of this, because she was not a techie. This is what I did. My code is now going to help power almost 20% of the internet. That also shows how old this was.

From there it was, well, now I’ve seen this process, now I’ve been involved in this process, what can I do to continue being involved in this process? And so I was working on a few small enhancements, or bug fixes, every release. And did that for, probably about three years before I got a job at Condé Nast, the magazine publisher. And part of my role there was to really help the company used WordPress better.

And so that gave me a lot of freedom and time, and I found one of the best uses of that time was to help make WordPress itself better. If it’s better for Condé Nast, it’s probably going to be better for everyone. And at the time, one of the challenges, it was right as the Git mirrors were added for WordPress. And I was like, okay well, now we have patches that are coming in through Git, coming in through SVN, coming in against the old Core repo, versus against the modern develop repo.

And so I worked on a tool called Grunt Patch WordPress, that made it easy for you to apply patches from anywhere. And you could just enter a ticket number, it would list all of the patches, and it would apply it automatically, no matter how it had been created. And working on that, I got involved more in the build tools, and was asked during the 4.1 cycle, if I would be willing to become a committer, and if I was willing to help maintain WordPress.

And it was a huge honour, and a huge burden that I would be willing to take on. My friend Daniel Bachhuber gave a talk a number of years ago, my condolences, you are now the maintainer of an open source software project. And in many ways, like you are taking on a great weight. Your changes are going to affect other people, and you are going to be responsible for making these changes.

It is still an honour that the community and other committers trust me enough to stay in this role, and that I have been able to make a number of changes, and hopefully make WordPress better in the process.

[00:10:41] Nathan Wrigley: It is such an interesting tale that. And really, I think the word that’s coming out of it for me was one that you just said, and it was trust. It feels like this whole process, from 2010 until the moment you were offered the Core Commiter status, it feels like it’s a work of building up trust, of doing things in a way which is fully transparent. People can see what you’re doing. You’ve done something important. Things worked, I guess, as well. And over time, people just begin to say, oh okay, yeah, Aaron, oh yeah, his name’s come up a little bit. And then eventually, that moment where you get the ability to alter WordPress Core.

But also, I guess the journey between 2010, okay, it was 20% of the internet. It was still big. But it’s like going from 20 to 43, let’s say about there at the moment. That’s a big jump. To be approaching half of the internet is incredible. And you illustrated, or you alluded to the fact that you sometimes probably feel the burden of that a little bit. You commit something, and millions of people are going to feel the effect of that. And millions of them will be utterly non-technical. And so they will not know when something goes wrong. They will not understand where to go and seek resolution to that, potentially.

And so that must add to the burden even more because, you know, if something goes wrong at my local shop, I just take it back and get another one. If something goes wrong with a website and I’m non-technical, then, yeah, that’s really interesting. So trust is what I’m imagining is the sort of essence of what you’re doing.

[00:12:14] Aaron Jorbin: Yes. So ultimately, user trust matters. I think it was Andrew Nacin who first said to me that, what makes WordPress work as well as it does, is the trust the users place in the software. The fact that users trust WordPress to auto update. Without auto updates, WordPress would be less secure. Without the ability to have a bug fix, or a security bug fix go out nearly instantaneously, it would be weeks before many people logged into WordPress. Potentially, you know, some people will set up a site, and set it and forget it. And they would get hacked if it wasn’t for auto updates. And so having that user trust really is a requirement for WordPress to be as successful as it is.

[00:13:05] Nathan Wrigley: So there’s the trust from the community, but also presumably there must be a fairly high level of trust between you Core Commiters. And I think you said about the number 100, something like that. Have I got that right? Is it roughly around there?

[00:13:17] Aaron Jorbin: It is about a hundred people that have committed over the course of the 21 years that WordPress has been involved. I think there’s about 50 active at the moment in some way, shape, or form.

[00:13:28] Nathan Wrigley: But a hundred broadly speaking, over the course of WordPress, and maybe 50 at the moment. I guess the trust between all of you must be fairly high. And I presume you must have back channels. Well, of course you do. But I’m really just leading you down the garden path of, tell us what these are.

How do you communicate? How do you maintain that trust? Is the trust, dare I ask it, is the trust ever taken away, and somebody has to be removed from that role? So yeah, let’s just get into that. How do you communicate? How do you ensure that trust is kept going? What are the ways that you build all of that up?

[00:14:03] Aaron Jorbin: First off, there’s very little back channel. There’s very little that is not discussed in the open, related to WordPress Core. Security is about the only thing that does not get discussed openly. Otherwise, there might be some conversations, especially when things are just not known. When people have, what I would refer to as a very half-baked idea. You might back channel, and have a quick side discussion with one or two other people, to try to make that idea a little bit better, so that you don’t feel like you’re going to embarrass yourself by sharing the idea.

Other than that, it is all in public. It is in Slack, it is on Trac tickets , it is on GitHub issues, it is on pull requests. That discussion is happening in public, and is open for anyone to really contribute their thoughts and their ideas.

And where the trust amongst us comes in, is the fact that I think, generally, there is very little ego involved in the people that are committers. We don’t feel bad if another person tells us our idea was wrong, or our idea isn’t the right solution.

It is okay for someone to tell me that my code is, bad or that my code doesn’t solve the problem. That’s not an insult to me personally. I think that all of the committers, there’s that idea that we are all going to be okay. We’re not going to insult each other. It’s not an instance of, what idiot made that decision? That’s not the type of thing that would ever be said amongst committers. It’s, okay, what information was had that guided that decision? How can we improve that information?

[00:15:48] Nathan Wrigley: Does the Core Commiter community, you mentioned that it was, over time it’s been a hundred, and at the moment it’s 50. Does it ebb and flow a little bit? In other words, are there people who just take a step back, maybe come back in six months time or something? Or are many of those people in some way able to commit to Core on a more or less permanent basis because, I don’t know, maybe they’re sponsored, or seconded by their company or something like that?

[00:16:08] Aaron Jorbin: Yeah so, I mean, I would say most of the people that are active are given support in some way, shape, or form. So myself, I have GitHub sponsors that, right now, are covering a portion of my life expenses. But others are paid full-time, whether it be by a hosting company, by a product company. And so most of the people that are active are supported, but not all of them. There are a number of committers that are still doing this on a very volunteer basis.

And people’s activity does ebb and flow. And so, I think a good example of this is myself. So I was very active, especially during the 4.1 to about 4.9 timeframe. But then I took on a different role, and didn’t have as much time. And so I stepped back from necessarily doing as many active commits, and more was there to help be in meetings, and provide some historical context, or to work on a couple of small things here or there.

And then after I left my most recent job, I was like, I’m taking a break. I stopped looking at computer screens for nearly six months. It was incredible. But decided that, ultimately, I like WordPress. I like contributing to what I view as a very important mission to democratise publishing. I think that, even if I don’t necessarily agree with everything everyone has to say online, I think they have a right to share it and a right to say it.

I want to help people do that. I want to help, whether it be a small business that just wants to get word out about its hours, to a large media company that wants to do journalism, to politicians who I may or may not agree with, wanting to get elected. I think that everyone has a right to share their beliefs online, and WordPress helps unlock that, and I like working on that.

[00:18:07] Nathan Wrigley: Nice. I think, if we were to poll every single person that’s used WordPress ever, which should be a difficult thing to do, but let’s imagine that we could. I’m imagining that the vast majority of those people would not necessarily have technical expertise or any interest in the project. They’re just using it, it’s functional to them. They may not even know that it’s called WordPress. They log into their website, and they do their thing. They create their content, and they click publish, and what have you.

But yet It just magically updates itself from time to time, whether that’s at the click of a button, or something, a little bit more automated. It just sort of happens in the background. And also, I would imagine that the listeners to this podcast, even though it’s very likely that they’re really quite crazily into WordPress, there’ll be this curtain between what they experience, and what Core is doing. How all those decisions are made, and how those changes get pushed.

Now, they may have noticed, obviously, that there are minor releases. So we go from 6.5, to 6.5.1, to 6.5.2, and then there are more major releases, 6.5 to 6.6, or 7 at some point, you know. But the major releases kind of have dates in the calendar, stretching right out into the future. So we try to get those dates for the whole year, and you can look those up online, and may provide that in the show notes. But you can see, in theory, they’re provided for. We’ve got a north star. We know that on this date we should be shipping the next version of WordPress.

But in between those major ones, we get these little ones which come around, like today. Little ones just happen, might happen in a week, might be two weeks, there might be a few weeks that go between them. How are those decisions made, and could we break it into the two parts? Could we do the major first, and then the minor afterwards? Because I think the major is more, how to describe it, there’s more thought goes into it on a long term basis.

There’s more north star of that, and the minor ones feel like sometimes it’s reactive instead of proactive, because of security and so on. So let’s do the major releases. How is it decided what features go in, what we’re aiming for, what we want to ship?

[00:20:05] Aaron Jorbin: So, I mean ultimately it’s decided what is going in by what is ready to go in, for a major release, and what people want to work on. Whether that is individuals that have a improvement that they really want to drive forward, whether it’s a company that decides that they want to donate, or devote, resources to working on maybe a larger feature that they think that will benefit their users, or hopefully benefit all users.

The decisions of what is ready to go in is basically a decision of the committers as a whole. And it’s often based on a consensus. And it’s not necessarily that everyone agrees, it’s that no one disagrees. So we will work in Slack, there will often be people that are guiding it. There are individuals that are wholly focused on just looking at the backlog of requests, and every idea that ever has been proposed. And saying like, okay well, this is a common theme, and this is a way to solve that problem. And we’ll be working towards that.

And so those major releases will often be set, generally by the project leadership, by Josepha and by Matt. And the dates might flux. Oftentimes we’re looking at trying to find a date that works for everyone in the world can be hard. There are holidays nearly everywhere, or nearly every day in some countries, and so trying to minimise the impact of those releases. And so not doing a release on a major Christian holiday, or a major Muslim holiday, is generally best possible solution.

For the minor releases, like you said, there’s kind of the reactive ones, in which case, those would generally be decided sometimes hours ahead of time. In the case of 6.4.1 two weeks ahead of time in other cases. So the recent 6.5.3 there was about one month of process.

And basically what it was was, it started with, some discussions in Slack of, okay, I think we’re going to want a maintenance release. Let’s try to put together a group of people that can lead it. And then, okay, amongst that group, let’s discuss possible dates. Let’s look at calendars. Let’s look at our personal calendars to make sure that we will be available. Let’s look at the holiday calendars to make sure that we’re not scheduling it during a bank holiday, or a religious holiday. And let’s try to do our best to make sure that people will be available for that release.

As far as what goes into the minor releases, it’s a lot of times like what bugs are known, what bugs are people reporting, what things can we fix in that timeframe? And so, a way that people can get involved is, there will generally be a post on Make Core about the release, and if you don’t see one, there’s always the weekly Dev Chat agendas, where you can comment on there. And commenting about a bug of, I think that this bug needs to be fixed in this.

We keep the scope rather tight, and that we try to focus the bug fixes solely on recently introduced bugs, rather than longer standing bugs, but anything can be discussed. If someone wants to try to make the case for it, they can try to make the case for it. The idea that, in the presence of new rationale, a good maintainer changes their mind often. And so even if the answer is initially no, that doesn’t mean the answer is no forever, and adding new information, adding data can really change minds a lot of times.

[00:23:53] Nathan Wrigley: You talked about a consensus there, and in fact, I think the implication of what you said was that, broadly speaking, the consensus is often there. There’s often broad consensus amongst you Core Committers about what needs to go in. In a way that kind of seems surprising, because you’d imagine that with 50 minds staring at a problem, there’s going to be 50 different solutions, and a lot of arguing and tussling.

But, again, I suppose that goes back to the trust thing that we talked about earlier, and maybe something different to trust, maybe it’s accommodation, or the ability to defer to somebody politely, as opposed to just wanting to railroad them.

And I feel maybe that in the corporate world, that whole governance model would break down reasonably quickly. Is that what you’re saying? That the 50 of you, or however many are in the, air quotes, room at the time, you really do have that? There is a consensus of almost everything that goes in. That’s remarkable.

[00:24:46] Aaron Jorbin: I would say we get to consensus. There is not always one to begin with. There is absolutely disagreements that happen, and disagreements that take place. And I would say that there are very few changes that aren’t without some sort of, often minor, disagreement. Of whether it be, I think this line needs more documentation, or I don’t like the variable name used here, ultimately nitpicky things.

All the way up to major, I don’t think that this is something that should be in Core disagreements. And you will have discussions, and sometimes that discussion will peter out, and not necessarily get to a quick resolution. Oftentimes though it will get to a resolution.

And another saying that I often use to guide me is, no is temporary, but yes is forever. Saying that code is not ready for WordPress isn’t saying that this code is never going in WordPress, or this feature is never going in WordPress.

There’s very few things I can think of that I would be like, this should never go into WordPress. But once it is in WordPress, it is the responsibility of all maintainers, all of the committers to maintain it, and to make it as best as it possibly can. Once it’s released from WordPress, because there will be features that are added that might get removed.

And so I think the font library is a good example of this. This was originally targeted for, I think, 6.3, and wasn’t quite ready. And then 6.4, it got very close, but then ultimately was pulled back. And then 6.5, after a lot of disagreement that people probably saw publicly amongst many committers, we did find solutions in a way to ship that, in a way that I think ultimately has been beneficial for the users of WordPress.

[00:26:39] Nathan Wrigley: Is the release lead for each release, so that, let’s say, for example, 6.5 or 6.6, has a release lead. Is the release lead ultimately responsible for the go, no go decision? In other words, if the 50 of you are, yeah, you can’t quite get that consensus that would be lovely, then it falls on the shoulders of an individual, and if you follow the project, you’ll know that that individual changes from time to time.

[00:27:05] Aaron Jorbin: Yeah. So, I mean ultimately it is Matt’s decision. And I for one, think that Matt has very good product sense, and WordPress is largely successful because of Matt. And I think that there are very few cases where I can think of where a problem has needed to be escalated to Matt to make a decision. Ultimately, you know, it’s often there will be a decision that gets made amongst the people that are most active, and working on it closely. And it’s not a highly conflicted situation. It’s very rare that the release lead needs to decide between two camps, if you will.

[00:27:50] Nathan Wrigley: I think sometimes the impression, out in the wider world, probably not in the community of WordPressers who follow the project really, really closely, but I do wonder sometimes if there is an impression that decisions, like any hierarchy, there must be somebody at the top making all these decisions and what have you. So that’s really nice to hear. That’s nice to hear that you think that’s a fair and equitable way of doing it.

However, I wonder how you feel about the, I can’t think of a better word, so I’m going to use the word chaos. The open source nature of the project can at times be fairly chaotic, because everybody gets a voice, everybody can put time into things, everybody can push their own agenda. I guess in a more corporate structure, it would be top down, whereas we’ve got a much flatter structure in WordPress. Everybody gets their go. Does it sometimes feel a little bit like that? And I’m not asking you to throw any names out, or throw anybody under a bus. But, does it occasionally feel, oh, can we just make the decision? Can we just do this, or this, which one?

[00:28:45] Aaron Jorbin: I think chaos actually is a great term for it because it often is, and especially when working around the clock. There are people contributing in nearly every time zone. And I think you would struggle to find a time of day where someone isn’t working on WordPress.

Luckily there’s very few decisions that need to get made at a snap of a hat. It is almost always a case where the decisions can be made asynchronously, where the discussion can continue possibly over the course of multiple days, or weeks. And the chaos works. And I know that a lot of people struggle with the chaos, and with understanding, well, how can I get involved? Who’s the person in charge that I need to talk to? Everyone is in charge, so you talk to everyone.

[00:29:38] Nathan Wrigley: Yeah, it’s not like if you’re in the corporate world where you just whip out the company Rolodex, for want of a better word, and you discover that, oh okay, they’re in charge of that department, that’s them. It’s a little bit more fine grain and nuanced, and things change all the time, and somebody’s gone on holiday. I love that then. So there is a kind of chaotic element to it, which I think you embrace, I guess. This is just the way it works, and it’s probably got massive upsides, as well as some interesting downsides as well.

In terms of the project, it feels like, since the dawn of the internet, so whenever that was, Tim Berners Lee, 35 years or whatever. Open source, at the beginning of the internet, was a real crucial underpinning for all sorts of things. The servers that we use, the CMSs that we use, and so open source projects just popped up everywhere. But then it feels, more recently, that competitive, market-based, commercial CMSs have come along, with probably a corporate governance structure. So not as transparent, but maybe more top down. So perhaps easier to manage in that way.

Do you have any feelings, or misgivings about open source in the near future, because of the competitive landscape that a CMS finds itself in now?

[00:30:50] Aaron Jorbin: I think that ultimately open source always wins. I think that you are better off betting on open source. I saw a tweet the other day about someone that has a shop on Shopify, and they woke up one morning and Shopify had turned them off. And they were like, well, our target was to make $25 million this year, but now it might be zero, because this decision by this company was to turn us off.

And thankfully with WordPress, you don’t have to deal with that. WordPress cannot turn a site off. WordPress cannot decide that a specific website is no longer going to be allowed to use WordPress. WordPress has the benefit of the GPL, GNU public license. And in that there are the four freedoms, and one of those is the freedom to run the software in any way you choose.

So that freedom, I think, ultimately is what gives open source its power, and its sustainability. WordPress itself is a fork of another project. I am never upset if someone says, well, I’m going to fork WordPress to do this, it’s like, okay. If your software is going to be better, that’s awesome. Open source wins.

I am not someone that’s ever been a big Drupal user, but I love Drupal. Drupal’s open source software. I don’t view Drupal as the enemy of WordPress. I think that, if a site wants to use Drupal because that’s the best open source software, or the best software it can find, awesome.

WordPress has been lucky to, you know, at various times, collaborate with people in the Drupal community. A number of years ago, I was running the WordPress meetup in Washington DC, and we organised what we refer to as the open source barbecue. And so it was the WordPress meetup, the PHP meetup, the Android meetup, and the jQuery meetup. And we just threw a barbecue for 200 people to come and celebrate open source, and eat barbecue.

[00:32:54] Nathan Wrigley: If we were just concentrating on the features, so not the ethics of owning the technology, who owns it, who gets to shut you down or not. Do you think that it’s easy for an open source project, of the breadth, and scale, and depth, and enormity of WordPress, to keep up with the features that the proprietary CMSs ship? Because they know their users, and because they don’t have to make decisions in committee.

Well, they probably do but, you know, the committees are probably much smaller, and managed from the top down. And they can ship features like this, and like that. They don’t need to necessarily worry. It’s a difficult question to encapsulate, but do you understand where I’m going with that? They can ship features perhaps more quickly than WordPress can.

[00:33:33] Aaron Jorbin: Absolutely. But I don’t think it is the ability to ship features quickly that leads to success. I think it’s the ability to ship the right features, and provide the right experience for users. And I think that experience includes the ability for them to decide to move. If you are not happy with your WordPress host, you can move hosts. If you are not happy with the agency that you are using, you can move agencies. If you are using a closed source CMS, your ability to move is a lot harder.

You get locked in, and ultimately that is harder for you. It might mean that you get features quicker. It might mean that you get up and running quicker, but at what cost? Everything has a benefit, everything has a cost. And I think that the benefits of open source just drastically outweigh the costs of using it. The fact that you are going to deal with volunteers running your software project in many cases.

There’s the old XKCD article, which has the tiny twig of holding up the software is one random guy in Omaha, Nebraska. And as much as possible, I think one of the benefits of WordPress is that there’s very few things where it’s one twig being held up by a single person. There are very few parts of the code base that multiple committers aren’t familiar with. And the beauty of how it’s been developed is we can look back in many cases, and understand why changes were made.

You’ll see in, if you ever look at a WordPress commit, there’s often be a long section. There will be a one sentence description, and then there might be a paragraph or two explaining what the change is. And then there’s also links to tickets, and often very important, the props of who worked on it along the way.

And so you can see, okay, well, these 15 people contributed to this. Oh, 12 of them aren’t active anymore, but there’s 3 of them that are. Maybe they remember, or I can look at the tickets that are referenced, and I can find the discussion that took place leading up to it. And that ticket, maybe that links to an IRC conversation from 15 years ago. We have the logs of that conversation, and can look back at what was discussed, and how did we get to this solution.

[00:36:03] Nathan Wrigley: I think history shows that people seem to like open source. You only have to look at the numbers, and the enormity of a lot of open source projects to realise that it definitely tends towards winning. I don’t know quite how to phrase that but, does that make sense? The graph tends towards open source on the whole.

Okay so, Aaron, given all of this, if somebody’s listening to this and they think, actually, I’d like to get into that, I’d be curious to see what this is like, dip my feet. Nobody’s suggesting that you have to show up and stay there for the rest of your life but, how do people begin this journey? Where are the best places to go?

[00:36:36] Aaron Jorbin: So if you want to contribute to WordPress Core, and I hope that everyone does at some point in their life, the best way to get started is to join the new contributor chats, which take place biweekly in WordPress Slack. And so if you go to make.wordpress.org/chat, you can join the WordPress Slack. If you go to make.wordpress.org/core, you can see the Core discussions, and you can see the meetings that are taking place.

Get involved. Find a issue that is bothering you, or that you think is going to make WordPress better, and add your thoughts. Think about like, if someone isn’t thinking about this, what is going to get them to think about this? Add context, add information. Even if you are not someone that can write code, maybe you can quickly sketch out an idea, take a picture of that and upload it.

Maybe you can share some data or share some stats from your company of, hey, this change took place and it’s actually caused a 10% drop for us in user signups. That is like, okay, well, that’s a data point that we can look at, and maybe use to come up to a better solution. This change would help speed up our website.

You can also test the changes that other people have proposed. There is the WordPress Playground now, that allows you to very easily test out a change. Just earlier today, there’s a change that was being proposed for 6.6 to remove the revisions panel from the sidebar. And a handful of us were like, I don’t think that’s quite right, here’s some alternate ideas. And then someone coded one up. A couple people looked at it and we’re like, that’s not the right way, how about this other way? And it was coded up, and I tested it and just was like, all right, here’s what I see. And it just took a couple of clicks of my mouse. It wasn’t a hard process to test and share a little bit of feedback for the project.

[00:38:41] Nathan Wrigley: So it’s not all about committing code. There are many more ways that you could help Core. So it may be that you identify problems, or test possible things that could go in, and just give your opinions. There’s loads of different ways that you can help in this initiative. And I will make sure that the, bits and pieces that Aaron has mentioned today all make it into the show notes. If you go to wptavern.com/podcast, and search for this episode, you’ll be able to find the show notes all attached there. It only remains for me, Aaron, to ask, if anybody is interested in just connecting with you personally, do you have a favorite place online where you send people?

[00:39:16] Aaron Jorbin: My WordPress site is my favorite place, which is at aaron.jorb.in. I’m also on a number of social media networks, generally with the username of Aaron Jorbin. A handful of them I think I use just Jorbin. Yeah, I would love to chat with people. If people see me at a WordCamp, please come up and talk to me. I can be a bit of an introvert at those, and so I might not approach people, but would love to chat with as many people as I can.

Something I used to do, that I’m going to try to get back into is, one lunch during the WordCamp, I’d sit down at a random table and just ask people, so how do you use WordPress? And you never know who you’re going to meet, and what they’re going to have to share if you do that.

[00:39:58] Nathan Wrigley: Yeah, that’s nice. And by the way, I’m incredibly jealous of your domain name. That’s just a stroke of luck that there’s a whole top level domain with your final two letters of your name in there. That’s lovely. I’ll add that into the show notes as well. But, Aaron Jorbin, thank you so much for chatting to me today. A real pleasure, thank you.

[00:40:14] Aaron Jorbin: Thank you so much for having me.