Tag: contributing

Juliette Reinders Folmer

[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 when contributions to WordPress deserve payment.

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, well, I’m keen to hear from you, and hopefully get you all 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 Juliette Reinders Folmer.

Juliette is a highly experienced professional in the field of coding standards. With a deep understanding of industry best practices, she has dedicated herself for many years to ensuring code quality and consistency within WordPress.

Juliette acknowledges that coding standards encompass more than just formatting and white space, they also play a crucial role in maintaining compatibility and preventing conflicts between plugins.

By adhering to these standards, developers can minimize errors, and fatal issues for end users. To facilitate the implementation of coding standards, Juliette talks about the importance of automated checks and continuous integration.

We chat about her commitment to WordPress coding standards, and how the work that she’s done in this field have made her a trusted authority. Through her contributions and guidance, she has helped countless developers enhance their code quality, ultimately improving the overall WordPress ecosystem.

We talk about Juliette’s role as one of the maintainers of WordPress Coding Standards or WordPress CS. Discussing the importance of consistent code and the challenges of maintaining, and funding, open source projects.

Clearly there’s great value in tools like WordPress CS. Consistency is key for developers, and using a tool like WordPress CS makes it easier for them to meet expectations and be productive. It saves time by automating manual changes, and helps prevent conflicts and potential problems with other plugins or WordPress Core. Juliette emphasizes the continuous nature of the project. Where updates to a variety of PHP projects need to be kept in sync with the WordPress side of things.

All that said maintaining open source projects like WordPress CS comes with its challenges. Juliette tells us about the importance of financial support and adequate resources to mitigate business risk, as projects that go on maintained can create dependency issues and pose problems during corporate audits.

She speaks openly about her decision to step away from contributing. The project is so crucial, but underfunded and Juliette thinks it’s time to draw a line in the sand. It’s time for contributions in return for payment.

It’s not just about financial contributions though. Juliette asks us to support the WordPress Community Collective, and for us all to explore other ways to assist the project. She highlights the need for all companies benefiting from WordPress to contribute towards funding more broadly, rather than relying on one or two of the larger companies in the space.

If you’re a contributor who was even pondered how much WordPress relies on volunteers, 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 as well.

And so without further delay, I bring you Juliette Reinders Folmer.

I am joined on the podcast today by Juliette Reinders Folmer. Hello, Juliette.

[00:04:41] Juliette Reinders Folmer: Hi Nathan. And you got my name right.

[00:04:43] Nathan Wrigley: I appreciate that. Thank you so much. I’ve had a little bit of a practice, let’s put it that way. I appreciate you being on the podcast today.

This is going to be a really interesting subject. It could get a bit nerdy, but I suspect that we’ll avoid large proportion of the nerdiness. But we’re going to be talking today about something which I suspect a lot of the people who tune into this podcast regularly may not know anything about. Hopefully during the course of this podcast we’ll alert you to why you should know about it, why it’s important, what it is, what it does.

But before we get into that, WordPressCS or WPCS, let’s ask Juliette just to introduce herself. Tell us a little bit about her background, working with WordPress, what she does and all of that. So Juliette, if that’s okay with you, over to you, little bio moment.

[00:05:32] Juliette Reinders Folmer: Oh dear. I did not prepare for that bit. Basically I’ve been self employed for good 20 years now, and as a general rule of thumb, I do whatever I like and I hope that sometimes people actually pay me money to do it. Which is not always great from a commercial point of view but it keeps me happy.

[00:05:51] Nathan Wrigley: Typically on this podcast we have people who are devoted to some aspect of WordPress. My understanding is that your technical expertise stretches beyond WordPress as well, PHP and various other different things. So is it true that you only operate in the WordPress space, or do you stretch a little bit further than that?

[00:06:11] Juliette Reinders Folmer: I’m all over the place. I sometimes say for people who are really in the WordPress community, see me as the PHP community reaching out and helping.

[00:06:20] Nathan Wrigley: Nice. So this podcast today is going to stem off a piece that I read on the WP Tavern. It was written by Sarah Gooding. If you want to find it I will link it in the show notes. But maybe for ease of use, it was published on August the 22nd 2023, and it’s called WordPress coding standards maintainer warns maintenance will be halted without funding, in quotes, this is an unsustainable situation.

That maintainer is you, and that’s what we’re going to talk about today. We’re going to talk about that unsustainable situation. But I feel that we can’t really talk about why it’s unsustainable unless we learn a little bit about what WPCS is, what it does.

I know that’s an enormous subject to deal with in just a few moments. But I wonder if you could paint a picture of what WCS is because I feel the listenership, there may be quite a proportion of us that don’t know.

[00:07:17] Juliette Reinders Folmer: Absolutely. Okay so WordPress, like most projects, have coding standards. And now when I say coding standards a lot of people think, okay this is about how code should be formatted, white space, whether things should have comments and doc blocks. You know, how code should look.

In part, yes that’s correct. We do have rules for that, because if code looks the same across your whole code base it makes it much easier to review code and only concentrate on the actual changes, instead of being distracted by all the inconsistencies in how the code is formatted. So, yes there are rules about code style, code formatting. But WordPress coding standards does much more.

It also encompasses a number of rules around best practices, just industry best practices. Best practices for how to interact with WordPress. So as a plugin you don’t want to conflict with other plugins. So there are certain best practices you can apply, like prefixing everything you put in the global namespace.

And if you apply those correctly the chance of your plugin conflicting with another plugin and creating a widescreen of death, fatal error, for end users is a lot smaller. And WordPressCS can help with that as well and has, on the one hand, has some rules for that. On the other hand, what you then get is WordPressCS as the package, because you have the written rule, but then you also have tooling which basically takes those written rules and codifies that into automated checks. Automated checks which can be run in continuous integration.

So every time someone puts some code online those checks can be run to make sure that the code complies with the rules you’ve agreed upon. And WordPressCS is one of those packages. It’s a package which takes those rules, codifies them in automated checks and then can be run on your code. And it doesn’t just check it and point out errors, it can actually auto fix a lot as well.

[00:09:29] Nathan Wrigley: So the enterprise of WPCS, and I should probably say that CS is the acronym for Code Sniffer. The enterprise is to create this suite of tests if you like, so that whilst you’re writing code, if you’re using CI, it’s constantly giving you alerts as to whether or not there’s a problem. We’ve identified that there’s a little problem here, you can take a look at it, and thereby mitigate the problems, right?

[00:09:55] Juliette Reinders Folmer: It can even do it even more directly. If you use a modern IDE, individual development environment like a PHP Storm or VS Code, it can even give you those notifications while you’re coding. It integrates with that kind of tooling. So while you’re typing your code, it can fix things for you and it can notify you of the things it doesn’t fix.

[00:10:19] Nathan Wrigley: So given the open source nature of WordPress, and the fact that anybody can download it and anybody can write a plugin for it, an interesting comparison would be something like the Mac App Store, or the Apple App Store where Apple, in effect, is the custodian of the code. Apple will go to great lengths to make sure that your code is compliant and it’s completely the opposite model. You put stuff into their ecosystem, they’ll do checks and make sure that it’s all compliant with oh let’s say iOS or something like that.

[00:10:50] Juliette Reinders Folmer: In a way a similar situation is in place in the WordPress ecosystem at large, because if you want a plugin to be listed on wordpress.org it goes through a list of quality checks as well. And they have some specific checks from that team, but some of the checks they use also are based on WordPressCS or are from WordPressCS.

[00:11:14] Nathan Wrigley: Yeah that’s a really good point. I was thinking also about the sort of third party plugin marketplace which exists in WordPress, into which anybody can drop their code. So it’s quite, you know, you can go to one of hundreds of thousands of websites and download a plugin which you can add to WordPress. And really there’s a bit of a gamble going on there. You’re hopefully able to determine that the code is good.

But a tool like WPCS will give you some guidance. You can run it yourself. It’s not like you have to trust the repo. If you went out and got third party plugins you could run these tests yourself. And just before we started the call, you were talking about if you were, let’s say an agency, and you had a particular need and you had three or four plugins that you thought might be useful. They would, all of them satisfy the requirements that you’ve got. But you could run them through something like WPCS, and get a real useful insight into well, whether or not they meet the standards, how compliant they are and so on.

[00:12:12] Juliette Reinders Folmer: Correct. You will get some noise messages about different white space requirements, for instance. But you will also get messages about, hang on, this is not prefixed and this could conflict. Or hang on, output is not escaped. This plugin may introduce XSS security vulnerabilities. There are actual sniffs in WordPressCS which scan your code for typical attack vectors, and whether your code is well enough defensive against those attack vectors.

[00:12:45] Nathan Wrigley: And I’m guessing that the enterprise of keeping WPCS maintained is like a road that you never reach the end of. You are updating it but there’s always the next change out in the, I don’t know, PHP ecosystem, which means that you can’t ever say well it’s done. Because PHP 8 comes along, then PHP 8.1 and PHP 8.2 and so we go.

So would that be fair to say? What kind of things is it sniffing for? Are we just working in the PHP space, or is it working with other things as well?

[00:13:19] Juliette Reinders Folmer: Well PHP_CodeSniffer as the underlying tooling, at this point is capable of scanning PHP, CSS code and JavaScript code. For the most part WordPressCS just focuses on the PHP code, because by now if we look at the whole ecosystem in development, there is plenty of other tooling available for CSS and JavaScript. Which wasn’t available when PHP_CodeSniffer started, because this is an old project.

I mean this project got started in 2005. So at that time that tooling was not available. So this was one of the only tools which could do something like this. The intention of PHP_CodeSniffer, because there’s so much other tooling available now for CSS and JavaScript, is to actually drop support for CSS and JavaScript. So with that in the back of our minds, our focus is completely on PHP.

[00:14:11] Nathan Wrigley: And so getting back to the question about how this is a never ending road, I’m assuming there will have been no point in the past, or predictably in the future where you’ll be able to say, okay this is done, because there’s constant work that needs to be done because the technology, the PHP, is always adding lots and lots of different things from year to year.

[00:14:34] Juliette Reinders Folmer: And it’s not just PHP. I mean if something changes in WordPress, WordPressCS needs to take that into account. For instance one of the scans is applied to plugins but also I think to WordPress Core is, are you using deprecated functions? Because those functions are deprecated for a reason. So you should use something else. There’s normally an alternative available.

Or are you using particular PHP functions for which there is a WordPress alternative which should be used? So if WordPress introduces one of those alternatives then WordPressCS needs to be updated to add a new check. If WordPress deprecates functions, WordPressCS needs to be updated.

On the other hand, like you already pointed out, every year there’s a new minor release of PHP, sometimes a major. But at least every year there’s a minor and those introduce new syntaxes. And in the past three, four years PHP has introduced so many new syntaxes it became really hard to keep up. All those syntaxes mean that code can be written in different ways.

And sniffs basically look for a certain pattern of code. But if code can now be written in a different way, that new way of writing code needs to be taken into account. To prevent false positives, as in throwing an error when there shouldn’t be an error. But also prevent false negatives, for people using the new syntax and the sniff not being able to understand it and throw the error which should be thrown.

Every single sniff basically needs to be reviewed after every PHP release, to be checked if it needs to take any of the new syntaxes into account. But before we can do that the underlying tooling needs to be updated as well, because it actually needs to recognise the new syntaxes.

[00:16:26] Nathan Wrigley: So a constant study.

[00:16:28] Juliette Reinders Folmer: Yeah it’s a whole domino chain of things and it’s basically a circle going round, because yes, we put dominoes in place and then we managed to get things merged in PHP_CodeSniffer. Then PHPCSUtils can update, and then we can update WordPressCS. And by that time a new PHP version has come out and we can start the whole circle again.

[00:16:49] Nathan Wrigley: We have this expression in the UK, “it’s like painting the Forth Bridge”. The Forth Bridge is a particularly long bridge in Scotland, and you begin painting at one end and by the time a year or so later they’ve got to the other end, well, the paint on the far end has now become corroded, and they’ve got to begin again so it’s this never ending cycle.

If you’ve heard of WPCS and have used it, I’m sure that you will recognise the utility of it. But if you haven’t, and as I said at the top of the show, I think there’s probably a lot of people listening to this who haven’t. How do we actually make use of it? How would a typical WordPress user get WPCS working, and giving them some insight into the suite of things that they’ve got in their WordPress site?

[00:17:32] Juliette Reinders Folmer: Okay. Well for people who are not used to command line, this might be a bit scary. You need the command line. Then again I mean, as I said, it integrates with IDEs so you can run certain things in IDEs as well. But as a general rule of thumb if you want to scan for instance, say you’re evaluating those four plugins to find out which one you’re going to install, like the example you used earlier.

The easiest way to use WordPressCS as part of your toolset when you’re evaluating, is to do so from the command line. And that means you need PHP installed. Well if you work with WordPress you generally should probably have PHP installed. You need Composer which is a package manager in the PHP world, like npm for JavaScript but then for the PHP world.

And then you need to install WordPressCS and that’s a Composer require. And if you don’t work with code yourself I would say use a Composer global require, then you can use it anywhere on your system without it being project specific. If you do work with code, please use it on a project basis and require it for the project, because it will also make it transparent for other contributors that you expect them to comply with WordPressCS.

So yeah, you can either install it globally or you can install it on a project base. And once you run the Composer require, it has all of that in the readme of course, so you can just copy and paste that command.

Once you run that everything is set up, and you can just run the commands to run WordPressCS which is vendor, bin, phpcs, dash dash standard is WordPress.

At the same time, most of the time, you will want to customise a little. For instance, I mentioned prefixing before to prevent conflicts with other plugins. If you want to check prefixes you need to tell WordPressCS which prefix to look for. If you don’t give it any prefixes, we cannot check whether things are prefixed. We need to know what to look for.

In the WordPressCS repo, an example rule set, which has some of the common things which you should add to a custom rule set to use. There’s also, in the wiki, quite a lot of documentation about what the various options are you can toggle on and off. That way you can set up a customer rule set and get yourself running in a more detailed way.

[00:20:08] Nathan Wrigley: I suspect that the proportion of people listening to this podcast who really never look at the code, they are, I don’t know, you maybe call them implementers or something like that, might be thinking well, why does any of this matter? What is the point? And I guess that’s something that I want to tease out.

I want it to be clear that unless projects like WPCS occur and continue to occur, the bedrock of the software, which we’re all using for free, gratis, is not going to be something that you can trust as much, I guess.

So I don’t know if there’s anything you want to throw into the mix there. If somebody was to come to you and say well I just use WordPress, why should I care about this? Why is this of interest to me? It’s a bit like, if I never go to a hospital, it’s not well we shouldn’t have hospitals because I’m perfectly well. Something along those lines.

[00:21:01] Juliette Reinders Folmer: Yeah, well if your site’s never been hacked that’s the same comparison. Your site’s never been hacked. So why do we need security checks and security reviews?

[00:21:10] Nathan Wrigley: So what would be the single, or maybe a couple of messages that you would tell people, this is why what I’m doing matters. This is why we all need to know that this project exists, and that it’s important.

[00:21:23] Juliette Reinders Folmer: There’s different answers for different levels. So for developers it definitely makes it easier for them to be high productive. Because if code is consistent it makes it easier to work with, to know the expectations, to review code, et cetera, et cetera. So it’s a productivity tool for them, including the auto fixing.

Some of the changes which may need to be done, if you’d need to do those manually that would take you like a week or two weeks. And if you use the auto fixer, it’s done in five minutes for you. So that is literally two weeks of work saved. That’s on the development level and the management, the IT department level.

If you are an agency who normally doesn’t use code, it’s more about, okay if I install this plugin, will it cause problems with other plugins? Will it cause problems for WordPress Core? Because there are plugins which will gladly override a global variable from WordPress Core and then WordPress Core breaks.

WordPressCS has checks against stuff like that. I already mentioned the conflict. If there’s two functions in two different plugins which use the same name, you have a fatal error and a white screen of death. Do you want your customer to get a white screen of death? No you don’t. So this tooling can help guard against that, can help prevent those kind of situations from happening.

[00:22:52] Nathan Wrigley: So I’m going to go back to the piece on the WP Tavern. I’m going to read the title again because I think it’s important for the next part of our discussion. WordPress Coding Standards maintainer warns maintenance will be halted without funding, this is an unsustainable situation.

So the person that is referenced in that article is you. You’ve obviously decided that this is an unsustainable situation. I think we’ve painted a picture as to why WPCS is an incredibly useful thing to have around. But i’m keen to know exactly how many people get their hands in the weeds with that tool? How many people do you have on your air quotes team? How many hours are contributed by those people per month, per year, whatever? Just give us an inkling as to how much goes into this important project.

[00:23:42] Juliette Reinders Folmer: As I already mentioned, WordPressCS is not a completely standalone tool. It is built on the shoulders of giants. The underlying tool, PHP_CodeSniffer, needs to be maintained primarily before we can even do anything in WordPressCS. That tool currently has two maintainers and I’m one of them.

There are outside contributors, and quite regularly we get an outside contributor with a pull request. But if you look at the bulk, to be honest, I don’t think I’m saying anything silly if I say that for the past few years a lot of that has come down to me. So that is the biggest giant we’re standing on.

Then we have PHPCSUtils which is a layer on top of PHP_CodeSniffer which makes writing sniffs easier. Because writing sniffs can be pretty complex with all the syntaxes you have to take into account. Maintained by me, completely.

Then we have PHPCSExtra, which is an external standard which WordPressCS uses quite a few sniffs from. About, I think more than 50% of the sniffs from PHPCSExtra are used in WordPressCS 3. Again, I’m the maintainer.

Remember that I mentioned that you install everything via Composer? There’s a Composer plugin which makes sure that all those external standards get registered with PHP_CodeSniffer. I maintain that together with one other person.

And then we have WordPressCS itself. And we have a maintainer team of three people. I’m really, really happy that there’s three of us. At the same time the majority of the actual code work comes down to me. Dennis would love to spend more time, but he hasn’t got the financial safety net to be able to do so without funding. Gary hasn’t got the time to do so anyway.

So I’m really happy with Gary and Dennis’s support, and for all the code review they do. But if we actually look at the code changes, nearly everything comes down to me.

[00:25:45] Nathan Wrigley: So we’re painting a picture here, and it’s a funny phrase to bring out but there’s this idea of the bus factor. And the bus factor is the idea that if, sadly, somebody was to be hit by a bus, and they were no longer able to contribute to the project. The bus factor being one is indicative that you only need to have one person removed from the project for the whole thing essentially to collapse.

And that’s basically what we’ve got here. We’ve got a situation where you are maintaining an awful lot of what you’ve just described, and you’re doing it, well, gratis. You’re doing it largely I’m imagining, and you can correct me if I’m wrong, you’re doing this in your own time for no financial benefit.

And I guess one of the things that’s come out of the article is that having done this for so many years, and contributed so many hours of your own time, you’ve reached the end of the road potentially about that and you feel that this situation is no longer sustainable. It’s a bit of a plea for help?

[00:26:56] Juliette Reinders Folmer: Yes. I mean basically over the past two years this has dominated my daily life, in a way which isn’t healthy anymore. It’s not you know a nice side project anymore. No, it’s literally what I spend nearly all my time on. And I’m lucky that I have a few stable customers where I can scrounge some hours here and there to be able to actually pay for my bread at the supermarket.

The balance is completely wrong now.. And I’m not alone. I mean this is valid for a lot of open source projects. But we’ve reached a point that the balance is so far off that this is just not sustainable anymore. I cannot afford to do this anymore. I cannot justify doing this anymore.

[00:27:44] Nathan Wrigley: Forgive me asking this question, and I hope it doesn’t come out the way that it might, but I’m going to ask it anyway. Do you have regrets around the amount of time that you’ve contributed over the past? So you mentioned that it’s requiring lots and lots of your time, and you’re basically doing this as a, almost like a full time job really.

Do you have any regrets getting into 2023 and that situation being the way it was? Or do you wish that you’d have managed to have this inspiration, if you like, this epiphany about enough is enough, a few years ago?

[00:28:18] Juliette Reinders Folmer: When it’s enough I say so. It’s felt like it’s been enough for about a year, and a large part of that is the fact that, in my perception, I think there’s a disconnect between the open source user nowadays and open source maintainers.

Open source users often don’t realise there’s no funding. They are not the product. And they come in with a sense of entitlements, and a sense of pressure which is being put on maintainers to release, and yes but you should do this. No, I shouldn’t do this. I’m doing this out of the kindness of my heart, and you should be a lot kinder to me if you want to make any suggestions for the project.

[00:29:01] Nathan Wrigley: Can I just clarify, have you been at the receiving end then of things which you, in the way that you’ve described, you’ve had requests in well let’s not beat around the bush, less than polite, shall we put it that way?

[00:29:13] Juliette Reinders Folmer: We actually at some point had to put, in a hurry, a code of conduct into the project. And we couldn’t wait for the WordPress project to get themselves sorted with a code of conduct, because we had an abusive user which was really going way too far.

[00:29:28] Nathan Wrigley: Yeah I mean like you said, I think the word surrounding that is entitlement, isn’t it? Somebody who believes that it is your role. You have become the person doing this and so well it must now be what Juliette does. Juliette must fix it at the moment anything needs fixing. And of course I think you’ve reached the end of the road there, and you’ve decided that enough is enough.

Does that mean that you are, well, let’s examine what that means. Let’s throw out a few scenarios. Does it mean that you would like more maintainers, so that you can step away from the project? Or is there a different possible outcome here where you would love to be continuing to work on this, but there needs to be some way of putting food on the table, i.e. payment in exchange for your time here? So I guess both of those options could coexist at the same time.

[00:30:16] Juliette Reinders Folmer: Yes, and that would be the ideal situation because the thing is, it would be great if we could get more maintainers interested and more people be willing to contribute structurally to the project. Except this type of work has quite a steep learning curve. So to get to the point where you can function as a maintainer for a project like this, and actually take it seriously in the way it’s been taken seriously over the past few years, that will require quite a lot of coaching, and guess who’s doing the coaching then.

[00:30:49] Nathan Wrigley: Yeah. So let’s ask that slightly different question. Over the past several years, have you had people go through the project? You know, that they’re interested in it, but they don’t stick around or is it literally that the door is open but nobody ever steps through it?

[00:31:04] Juliette Reinders Folmer: There’s a number of different types of contributors. You have the drive by contributor. We will say okay, we have this sniff which we use in our own company, I’m going to throw it into PR and just drop it in the WordPressCS repo, because it could be useful for other people.

You do an extensive review and give them feedback of you know, this needs changing that need changing. Because if you use it in your own company you can take some liberties because you know what the agreements are, what code is based on in that company. Except you can’t take those liberties with a project which has this many users as WordPressCS. So we require a higher quality. And the drive by contributor will just not respond to that review at all, and just let the PR rot and die. So that’s the one.

Then you have, and I’ve seen two, three people over the past five years maybe in WordPressCS like that, will come in and actually understand what they’re doing and how to do a PR. But then don’t have enough time or have a family, have a job and their employer doesn’t allow them to contribute to open source regularly, et cetera. Or they get moved into a different position in their job, and then don’t have time anymore.

Those are like the little jewels which I’d like to hold onto, and cherish and cuddle and watch to flourish in the project. Except they are rare and unfortunately we rarely manage to retain them.

And then you have the, oh gosh how should I call it? What’s that called again? That month of code thingy, Oktoberfest. Yeah, I’m going to make a one character change in your readme. Let’s waste maintainers time, kind of PRs. Just so they can get a t shirt kind of thing.

There’s a couple of different types of contributors. A lot of contributors, or people I talk with, will say like, oh I’d love to contribute. I’m going to write a new sniff. And I’m like okay but do you actually know what you’re doing already? No, you don’t. Okay. So now you’re going to write a new sniff, and that needs a lot of coaching to get to a point where it’s actually mergeable. Instead of helping with the grunge work which needs to be done every time, every year, at every WordPress release, every PHP release. And actually learning from the patterns you see in others existing code.

And I know that the grunge work is boring, but it needs to be done, and we need people who will put up with the grunge work because otherwise the code base will just grow with new sniffs but nobody’s maintaining.

[00:33:47] Nathan Wrigley: Yeah. So I guess what we’re discovering here is, A the project is important. B there’s not many people meaningfully contributing to it, apart from the ones that you mentioned including yourself. I think you mentioned two other people.

[00:34:02] Juliette Reinders Folmer: We do get some contributions which are meaningful, absolutely. I’m not dissing that at all. But it’s the exception not the rule, in my experience. And that’s a shame. I mean I really would love to see more meaningful contributions.

[00:34:16] Nathan Wrigley: Yeah okay. Thank you for clarifying that. That’s good. But it also sounds as if you’re not quite at the point where you want to completely distance yourself from this project and never touch it again. I think I’m right in saying that a possible desirable outcome would be that you found a way to make this work for your setup.

And really what I’m talking about there is finance. Am I right in saying that you would continue this work if you were able to make it a job, if you like, and be paid for it?

[00:34:49] Juliette Reinders Folmer: Absolutely. I mean I enjoy this kind of work. That’s obvious otherwise I wouldn’t have gotten involved in the whole stack, and even projects related to which I haven’t even mentioned yet. I do enjoy this kind of work, but I do not enjoy the abuse, and the abuse is something I will not put up with anymore. Only ever put up with if it’s paid, if I get paid for it.

[00:35:11] Nathan Wrigley: So since the article was published on the Tavern, so we’re recording this just for context kind of probably about 20 plus days since that piece was published. There were a lot of comments, an unusually large amount of comments. So this topic is of great interest to people. And I wondered, given that there was great interest and a large amount of comments there, I wondered if anybody had figured out what your requirement was, and had approached you. In other words has anything changed or is it still the way it was?

[00:35:42] Juliette Reinders Folmer: I can see some parties being interested in contributing to a solution, but I’ve not seen a solution yet. But one of the things which has changed, and which I think is an improvement, and i’m really hoping that will allow people to contribute to the funding of the project, is that the WPCC has in their open collective, has opened a project for WordPressCS and the stack around it, to raise funding for that.

[00:36:15] Nathan Wrigley: So just for clarity, the WPCC is the WordPress Community Collective. And what you can do is you can go over there and they have a handful, at the moment, of projects which you can donate to. And it looks like you have been added to that, or at least the WPCS project has been.

Do you have an amount, like a target that you want to get to in order for this to be possible for you? Or is it more a, well let’s just see where this goes, and bit of blue sky thinking, hopefully some people will help me out?

[00:36:45] Juliette Reinders Folmer: I have a target in mind. I’m not comfortable calling that out on air though.

[00:36:48] Nathan Wrigley: No that’s fine. So that’s where we’re at. As of the 5th of September 2023, we’ve got this incredibly important project which underpins the sort of security, the confidence that you can have in WordPress and the plugin ecosystem surrounding it. But we’ve got this one or two or three, but largely one person maintaining that entire project. But it looks as if, unless something radically changes in the near future, as if that whole edifice might tumble. How much more time are you going to give this before you actually finally call it a day? Maybe that’s not even in your thinking, and maybe it’s you know you’re hoping that it will change

[00:37:29] Juliette Reinders Folmer: Well I’m definitely hoping it will change. As a rule of thumb I’m basically not touching the code anymore. Not until there is sight of a solution.

WordPressCS is definitely not an exception. I mean I know open source projects where there’s much bigger problems with abuse than in WordPressCS. I’ve known people who’ve had death threats in their DMs, et cetera, et cetera. That open source and abuse is a whole different topic, but it’s definitely not isolated to WordPressCS. And WordPressCS need for funding is also not isolated. I mean the accessibility project also needs funding. There’s other projects in the periphery of WordPress which could do with funding.

I think that it’s very easy for people to think, like okay but WordPress is open source and yeah there’s some big companies earning money so they should pay for everything. I do not agree. I think we should as companies which earn money from WordPress, that all those companies should get together in something like the WordPress Community Collective and fund those projects.

It shouldn’t come down to one or two of the bigger ones. It should come down to all of us because all of us are making money off it. Well all of you, because I’m not.

[00:38:48] Nathan Wrigley: Obviously the nuts and the bolts of that mechanism, the bits and the pieces that would need to be configured to make that work, i’ve come across that project yet. But that is a really interesting idea, isn’t it? The idea that there’d be somewhere, and the WPCC does seem the best bet we’ve got at the moment.

It feels a little bit like five for the future or something like that. But instead of it being time, it’s, okay we’re a big company we make money off these things. We use PHP, we use the code sniffing, we do these plugins that are open source and so on. So let’s just put our flag in the sand and say we’ll donate 5% of our resources, and then that organisation, whatever it was, the WPCC or something else that’s new, could then distribute those resources and people like you could dip into that pool. That seems eminently sensible.

[00:39:36] Juliette Reinders Folmer: I’ve written about this years ago already. It’s also about business risk. If you run a business which is built on an open source project, and you do not contribute back financially, as well as with people. You run business on quicksand. You are literally running it on quicksand. Any corporate audit type of your company will say you’ve got an unmitigated business risk.

You have risk that those projects which you’re not contributing to, which you’re not paying for, for which don’t have a service contract, are just going to go unmaintained. And you are so dependent on these projects, you should mitigate that business risk. And one way of doing that is with funding. Another way is with resources, and preferably with both.

And it’s not just WordPress yes, it’s all the open source projects in the stack. Go through the whole stack. You have PHP Units probably in your stack. You have Apache in your stack. You have a Chrome browser in which you test things in your stack.

And Chrome, yes, everyone associates it with Google, but it’s built on top of Chromium which is open source. You might use Mastodon as a communication channel. Make sure you also fund your Mastodon instance. It’s the whole stack of all those open source projects which need funding. So go through your stack. Do a proper inventory and fund them. This is the only way to mitigate the business risk all of those companies are running.

[00:41:05] Nathan Wrigley: Yeah, I think you’ve made a really compelling case for this. In that, A, we’ve painted the picture of what it is that you’re involved in, and how important it is as a real bedrock of reliance and the ability for us to be confident in WordPress. And then we’ve also painted the picture of how the underpinnings of that aren’t very stable. Because all of us, unless we’re incredibly lucky, have to put food on the table and we have to be paid for our work.

And it does sound like the balance, certainly in your case, has gone really far in one direction, and you are the single biggest contributor to that project. And so it makes it all the more important that something like this gets funded, however that may be.

Now if you happen to be listening to this podcast and you feel that you are able to change the direction here. Juliette, what would be the best way? It sounds like WPCC, which I’ll link to in the show notes, may be the best way at the moment. But I don’t know if you’ve got any other intuitions about how this project might be helped.

[00:42:07] Juliette Reinders Folmer: Companies can always reach out to me, DM me, Slack, or DM the maintainers as a collective. Gary, Dennis, and me on the WordPress slack. Open Collective is definitely welcome to receive funding for us. Keep in mind, I look towards the companies. I do not look to individual developers to fund this. Because, yes, they feel it most if projects like this don’t continue. But they are the ones we should talk to management and tell management to fund it, because it shouldn’t come down to individual developers. And one time contributions are very welcome, but recurring contributions are what keeps the project alive.

[00:42:48] Nathan Wrigley: Well let’s hope that there’s somebody listening to this for whom it has raised awareness enough. Let’s hope that we can come back in a year’s time, do another podcast episode and we’ll be talking about a different setup. Let’s hope that that’s the case.

Juliette, I really appreciate you being on the podcast today, and telling us an awful lot about your personal circumstance and things. So I really appreciate that. Thank you so much.

[00:43:11] Juliette Reinders Folmer: You’re very welcome. I enjoyed being here, and hopefully my bakery around the corner will enjoy it soon as well, because I can then actually start paying them.