Open Sourcery – Episode 1 – Juliette Reinders Folmer  ## Metadata - Author: [[The Open Sourcery Podcast]] - Full Title: Open Sourcery – Episode 1 – Juliette Reinders Folmer - Category: #podcasts - URL: https://share.snipd.com/episode/bed34de8-0730-4ef1-a8c3-7ce166fd6a29 ## Document Notes ## Highlights - **Disconnect Between PHP and CMS Communities** - There's a disconnect between PHP internals and CMS communities like WordPress, with low awareness until release time. - CMS communities need to engage more proactively with PHP internals to influence development. Transcript: Speaker 1 Help? Or is it perhaps the way that we gather and listen to feedback? I don't think the tooling is the problem. I think more than anything that there is a disconnect between the PHP community and communities like WordPress where the majority of WordPress developers have very little awareness Of what's going on in the PHP community until there is a release and then they leave my migration guide if at all. And the communities like the WordPress community basically need to start stepping up. They step up and get involved with PHP internals. Not just be, we'll take whatever is thrown at us but we want to be involved and take part in it. PHP internals has about reputation. It's nowhere near as bad as it used to be. But again, if I look at it from my personal point of view, I choose very carefully how I want to spend my time. And I've so far chosen not to spend it there because I kind of feel I would probably get too frustrated. And in that case, my energy is better spent elsewhere. But there might be people who have different frustration thresholds, who would be better suited to have that conversation. And I would very much like to hear from them. I would very much like to help them and able them to get involved with PHP internals because I do think our forests need to be hurt. And I do think the only way we can get that to happen is by speaking up and by getting involved. Interesting. So I'm going to share an opinion that I have with you. I've had the opportunity to interview folks from the United States, Canada, those sort of Western world, if you will. I've also had the opportunity to interview folks from Europe, folks like yourself, folks like Alon. And I actually asked Alon the same question. I said to him, when I interviewed him for the podcast, I said, I get the sense as a South African. I get the sense that the Western, sort of US, America, Canada, that side of the world, developers, contributors, they tend to have a very, what's the word I'm looking for? Get it done, mentality. Whereas the European developers and folks that are involved tend to have a bit more of a, and I think he used the term academic mentality. So a little bit more thoughtful about what happens and the way things are done. And so the point that I'm trying to get to is that do you think that the people who are sort of getting involved in these kinds of things or should be getting involved in these kinds of things Are not doing it because they don't think in the same way? Do you think that there is a, almost a, if we look at WordPress as an example, WordPress, in my opinion at least, is kind of very US centric. It's getting better over time, but it is still very kind of US centric. And so they don't think about the academic side of what happening in PHP and making sure they're keeping up to date with their things. Or do you think it's just a case of, I will worry about it when we get there? To be quite firm, I'm not 100% sure what you're asking me. Okay. Is this about the WordPress community? Is this about the PHP community? Is this, it's about, it's about what you were saying about as a, almost as a WordPress community or as a Drupal community or as a Laravel community, we should be getting more involved In what PHP is doing is what you were saying earlier, right? Are we not, my question is why are we not doing that? What should we be changing? What should we be improving? Or is it just a case of people just taking the time to see what's going on? It's a case on the one hand of people having the interest, having the know-how to have constructive conversations in those channels. I honestly don't think it's a cultural thing. Okay. No, I mean, the open source community is a global community. Both in the PHP sphere as well as the WordPress sphere. And you're saying that WordPress is heavily America-centric. I don't necessarily identify with that. Okay. If you even look at the Word comes, Word Compurup has been ([Time 0:21:44](https://share.snipd.com/snip/2315f7cd-0c82-424e-ab25-7761be788c53)) - **Create CMS-PHP Working Group** - Form a working group with representatives from CMS projects to monitor PHP internals regularly. - This group should identify potential impacts and represent concerns effectively in PHP development. Transcript: Speaker 1 And what the way I can do? What should I be doing to prevent this from happening in the future? I'd like to very much invite you to join an idea of the planning with to get set up a working group of people from various CMSs, including WordPress, to regularly meet and say every two Weeks, keep an eye on the internals, PHP internals. Discuss with that group. Hang on. Is this something which will impact our frameworks and if not, let's move on. If it is, which person of our working group is going to spearhead this discussion and going to focalize our concerns about what's happening now in people. Get people from that working group to speak up about different subjects. Right. Right. That would entail reaching out to the jumlers, the Drupal's, you ([Time 0:37:30](https://share.snipd.com/snip/4232dc50-2e6f-42d9-b3d4-ce4029d6ded8)) - **RFCs Understate Compatibility Risks** - PHP RFCs sometimes understate backward compatibility impacts, notably with strict mode changes causing fatal errors. - Properly analyzing and disclosing impacts in RFCs would improve decision-making and developer preparedness. Transcript: Speaker 1 Future? Well, one thing would be, and now I'm going to be controversial. Okay. I have honest, backward compatibility impact analysis in RFPs. Okay. If you look at the RFP for a stricter engine, which basically made of a turn-strict mode on for all the PHP internal functions, whether you want it or not, the actual impact statement There is this will impact PHP itself more because we have to adjust our tests. It will be very rare for this to have any impact on user land. The fact of the matter is it has a huge impact on user land because user land was used to PHP being a loose type language and juggling. If you combine that particular change with PHP 8 adding lots of type declarations to functions which didn't have them before, changing return types and changing sometimes the parameter Types of PHP internal functions, all of those now go from not even a warning or a notice to fatal error in one go. Right. That is specifically what I am talking about with a perfect storm. That is something which was completely not addressed and not even mentioned in the impact statements of the RFP. I think that had been known in advance, the voting might have been different. Right. Okay. So I am going to preface this question with a, I am not here to try and point fingers at anybody. I am very much a why can't people just get a long kind of guy. My contribution ([Time 0:39:04](https://share.snipd.com/snip/f160ecbf-4400-4464-8f01-8996fc33a0eb)) - **PHP Core Contributors are Mostly C Developers** - PHP core contributors tend to be C developers, causing a disconnect from PHP language real-world usage. - Including experienced PHP developers from big projects could improve impact assessment in core decisions. Transcript: Speaker 1 Haven't had to deal with the PHP 4s and 5s of the world. They almost live in a perfect world where they don't have to worry about too far backwards compatibility. Or am I just talking out of the hole in my head here? No, I think you have a point there. But I don't think that's the only thing. I do think it's part of it. I do think that there, I mean, and it's not surprising. I mean, let's be fair, PHP core is written in C. The people who contribute to PHP call in general are C developers, do not PHP developers. And that makes for a natural disconnect. And yeah, I do think it would be helpful to have more voices from a big open source project because of, you know, they actually work with PHP every day. And some of the developers and people who are voting rights in PHP core actually do work with PHP every day, but not everyone. And I think the people who are identifying as a C developer rather than a PHP developer probably might have more of a struggle in gouging what the impact of a proposal is when they make It instead of the people who actually come from usual on PHP. And I don't blame them. I don't think that I think it's very logical that that's happening. I think it might be a good idea to maybe couple people with a mentor. It has got more usual on PHP experience. That's interesting, Ben. Would you say that, and this is difficult for me to even answer because I haven't been following PHP development for much time at all. You might have a better understanding. You might not. I'm just asking. But do you feel like the people who used to be those voices have since moved on? And that's why those voices aren't there anymore? Partially. Okay. Partially. Not completely. But yeah, but different ([Time 0:43:17](https://share.snipd.com/snip/4e02e080-598c-4fec-8fac-e78cb249cae4)) - **Prioritize Tests for PHP 8 Upgrade** - Before upgrading to PHP 8, ensure your project has high test coverage with unit and integration tests. - Tests detect breaking changes that static analysis cannot, reducing the risk of fatal errors. Transcript: Speaker 1 To the last bit of this interview? More than anything, I would really, really, really like to tell anyone listening who manages a PHP project, whether it's open source or close source, doesn't matter. Please, before you move on to PHP 8, make sure you have tests in place, unit tests, integration tests. Make sure you have tests with high code coverage as in testing all the different paths. Make sure the unhappy part is tested. And make sure you strict assertions and then test on PHP 8, because this change to PHP 8 really can break a lot of things. So be careful and be warned. And for projects with high code coverage, it's a relatively easy change because the test will point out all the problems. But without tests, it's really hard because most of these changes cannot be detected by static analysis. And I'm saying that as the main author currently of PHP compatibility, we can detect a lot, really a lot. But we do not have access to runtime type or failure of variables. And all of this is to do with runtime type and failure of variables. And something like PHP compatibility will not be able to detect this properly. Something like PHP stand again will not be able to detect this properly. They will guesstimate. But you might get a report with a thousand issues out of which there are 950 false positives. Because we again, static analysis tools doesn't have access to this. The only real way to guarantee your own projects PHP 8 compatibility is to have tests. And that does mean ([Time 0:50:20](https://share.snipd.com/snip/1c37315b-3513-443e-980d-30ce64bad204)) - **Use Trusted Resources for Testing** - Beginners should explore resources like Chris Hartjes' books and PHP Unit documentation to learn testing. - Official documentation contains many underused features crucial for effective testing. Transcript: Speaker 1 Know. Nobody's ever explained it to me. Nobody's shown it to me. I don't know even know where to start. What resources would you point them to? Wow. This is very, very biased. I mean, the first thing which comes to mind is Chris Hartchus has written a number of books from Phid. And please go and have a look at his books. They're good. Second of all, don't ever underestimate the value of documentation of test tools. The documentation of PHP unit alone is a treasure trove of things which are unused because people are not aware that that's part of PHP unit. So there's lots of tools and resources out there. I don't have a preferred one. But if you're really green fields, I'd say start with one of the books or videos by Chris Hartchus. No, excellent. That is actually how I started. So I can resonate with that statement. I don't know at what point I started following him. But yes, when I made that decision, I went looking for people and I think that's how I found him and I started with his content. So I'm glad you mentioned it. I would have if you didn't. ([Time 0:57:47](https://share.snipd.com/snip/65e6c173-9369-4836-8e2c-b2f5074a5314)) - **Git Extensions as Essential Tool** - Juliet's primary development tool is Git Extensions, offering a GUI that mirrors command line Git terminology. - This tool bridges command line and GUI usage, improving productivity especially on resource-limited machines. Transcript: Speaker 1 Or IDE or text editor? What is the tool that you use the most every day? My most important development tool realistically is get extensions. Okay. Is a GUI or forget, live in get extensions. And it's not code editor as such that you do have the ability to edit code directly in the GUI, which I do actually use once in a while. But get extensions is where I live and breed. Okay. If we're talking editors, I mean, I use several. I often use a really small unknown one called context and nobody's ever heard of it. Nobody uses it. But it's very lightweight. And when you have a lot of other things running on your machine at the same time, lightweight is a good thing. And I've just switched to a new desktop. My previous desktop really would not have been able to handle a full blown IDE combined with all the other things I'd be running at the same time. A new machine I'm hopeful. This is why I ask these questions because I like to know what other people are using because it might spark something that I might decide to switch to. So I'm always interested to know what folks are using. Yeah. Well, I can very highly recommend get extensions. It is a primarily Windows project. But with Mono, it can run on Linux and Mac as well as far as I know. But yeah, for me, I tried something like four or five different Git goos because I'm far more goo-ing oriented than command line, even though most of the projects I'm currently working On running on the command line. Yeah. It's a bit of a contradiction there. But yeah, the great thing with Git extensions is it uses exactly the same term, monology as the command line. So I can talk to anyone who was used to the command line and use the same terminology, use the same phrases, be able to exchange, you know, work around or productivity tips. And we know what we're talking about because we use the same language. If you want to, it will show you literally all the command line commands it uses. So the bridge between command line and GUI is there. But it's so effective. It just helps me get my work done so much quicker than I ever could ([Time 1:01:20](https://share.snipd.com/snip/f03035be-c7c4-45c0-bf2c-247f3c61244d)) - **Prioritize Energy and Trust Outcomes** - Select tasks that energize you and avoid those that drain energy to sustain long-term contribution. - Trust that pursuing what you enjoy will lead to positive outcomes despite uncertainties. Transcript: Speaker 1 It just helps me get my work done so much quicker than I ever could on the command line. We could. Excellent. Excellent. Well, I'm definitely going to check that one out. The next question I want to ask is kind of a little bit more philosophical, if you will. And I'm going to sort of give it a set time frame. If you could go back in time to the point where you left, working for that employer you mentioned and you went and worked for yourself. So think about that time of your life. Or maybe even the time before you got very involved with open source community. So think about your open source journey. If you could go back and give yourself one piece of advice that knowing that now would have made life easier for you, what would that have been and why? Always pick yourself first. So choose to do the things which give you energy, not drain your energy. And have faith in the ([Time 1:03:58](https://share.snipd.com/snip/e1fe272e-fdd5-4376-adf3-b5e16f4678cb))